I see this concept appear in discussions surrounding virtualization all of the time.\u00a0 This is a broader, more general concept but virtualization is the “hot, new technology” facing many IT organizations and seems to be the space where currently we see the “just because you can, doesn’t mean you should” problems rearing their ugly heads most prevalently.\u00a0 As with everything in IT, it is critical that all technical decisions be put into a business context so that we understand why we choose to do what we do and not blindly attempt to make our decisions based on popular deployment methodologies or worse, myths..<\/p>\n
Virtualization itself, I should point out, I feel should be a default decision today for those working in the x64 computing space with systems being deployed sans virtualization only when a clear and obvious necessity exists such as specific hardware needs, latency sensitive applications, etc.\u00a0 Baring any specific need, virtualization is free to implement from many vendors and offers many benefits both today and in future-proofing the environment.<\/p>\n
That being said, what I often see today is companies deploying virtualization not as a best practice but as a panacea to all perceived IT problems.\u00a0 This it certainly is not.\u00a0 Virtualization is a very important tool to have in the IT toolbox and one that we will reach for very often, but it does not solve every problem and should be treated like every other tool that we posses and used only when appropriate.<\/p>\n
I see several things recurring when virtualization discussions come up as a topic.\u00a0 Many companies today are moving towards virtualization not because they have identified a business need but because it is the currently trending topic and people feel that if they do not implement virtualization that somehow they will be left behind or miss out on some mythical functionality.\u00a0 This is generally good as it is increasing virtualization adoption, but it is bad because good IT and business decision making processes are being bypassed.\u00a0 What happens is often that in the wave of virtualization hype IT departments feel that not only do they have to implement virtualization itself but do so in ways that may not be appropriate for their business.<\/p>\n
There are four things that I often see tied to virtualization, often accepted as virtualization requirements, whether or not they make sense in a given business environment.\u00a0 These are server consolidation, blade servers, SAN storage and high availability or live failover.<\/p>\n
Consolidation is so often vaunted as the benefit of virtualization that I think most IT departments forget that there are other important reasons for doing implementing it.\u00a0 Clearly consolidation is a great benefit for nearly all deployments (mileage may vary, of course) and is nearly always able to be achieved simply through better utilization of existing resources.\u00a0 It is a pretty rare company that runs more than a single physical server that cannot shave some amount of cost through limited consolidation and it is not uncommon to see datacenter footprints decimated in larger organizations.<\/p>\n
In extreme cases, though, it is not necessary to abandon virtualization projects just because consolidation proves to be out of the question.\u00a0 These cases exist for companies with high utilization systems and little budget for a preemptive consolidation investment.\u00a0 But these shops can still virtualize “in place” systems on a one to one basis to gain other benefits of virtualization today and look to consolidate when hardware needs to be replaced tomorrow or when larger, more powerful servers become more cost effective in the future.\u00a0 It is important to not rule out virtualization just because its most heralded benefit may not apply at the current time in your environment.<\/p>\n
Blade servers are often seen as the<\/em> choice for virtualization environments.\u00a0 Blades may play better in a standard virtualization environment than they do with more traditional computational workloads but this is both highly disputable and not necessarily applicable data.\u00a0 Being a good scenario for blades themselves does not make it a good scenario for a business.\u00a0 Just because the blades perform better than normal when used in this way does not imply that they perform better than traditional servers – only that they have potentially closed the gap.<\/p>\n Blades needs to be evaluated using the same harsh criteria when virtualizing as when not and, very often, they will continue to fail to provide the long term business value needed to choose them over the more flexible alternatives.\u00a0 Blades remain far from a necessity for virtualization and often, in my opinion, a very poor choice indeed.<\/p>\n One of the most common misconceptions is that by moving to virtualization one must also move to shared storage such as SAN.\u00a0 This mindset is the obvious reaction to the desire to also achieve other benefits from virtualization which, if they don’t require SAN, benefit greatly from it.\u00a0 The ability to load balance or failover between systems is heavily facilitated by having a shared storage backend.\u00a0 It is a myth that this is a hard requirement, but replicated local storage brings its own complexities and limitations.<\/p>\n But shared storage is far from a necessity of virtualization itself and, like everything, needs to be evaluated on its own.\u00a0 If virtualization makes sense for your environment but you need no features that require SAN, then virtualize without shared storage.\u00a0 There are many cases where local storage backed virtualization is an ideal deployment scenario.\u00a0 There is no need to dismiss this approach without first giving it serious consideration.<\/p>\n The last major assumed necessary feature of virtualization is system level high availability or instant failover for your operating system.\u00a0 Without a doubt, high availability at the system layer is a phenomenal benefit that virtualization brings us.\u00a0 However, few companies needed high availability at this level prior to implementing virtualization and the price tag of the necessary infrastructure and software to do it with virtualization is often so high as to make it too expensive to justify.<\/p>\n High availability systems are complex and often overkill.\u00a0 It is a very rare business system that requires transparent failover for even the most critical systems and those companies with that requirement would almost certainly already have failover processes in place.\u00a0 I see companies moving towards high availability all of the time when looking at virtualization simply because a vendor saw an opportunity to dramatically oversell the original requirements.\u00a0 The cost of high availability is seldom justified by the potential loss of revenue from the associated reduction in downtime.\u00a0 With non-highly available virtualization, downtime for a failed hardware device might be measured in minutes if backups are handled well.\u00a0 This means that high availability has to justify its cost in potentially eliminating just a few minutes of unplanned downtime per year minus any additional risks assumed by the added system complexity.\u00a0 Even in the biggest organizations this is seldom justified on any large scale and in a more moderately sized company it is uncommon altogether.\u00a0 But today we find many small businesses implementing high availability systems at extreme cost on systems that could easily suffer multi-day outages with minimal financial loss simply because the marketing literature promoted the concept.<\/p>\n Like anything, virtualization and all of the associated possibilities that it brings to the table need to be evaluated individually in the context of the organization considering them.\u00a0 If the individual feature does not make sense for your business do not assume that you have to purchase or implement that feature.\u00a0 Many organizations virtualize but use only a few, if any, of these “assumed” features.\u00a0 Don’t look at virtualization as a black box, look at the parts and consider them like you would consider any other technology project.<\/p>\n What often happens in a snowball effect where one feature, likely high availability, is assumed to be necessary without the proper business assessment being performed.\u00a0 Then a shared storage system, often assumed to be required for high availability, is added as another assumed cost.\u00a0 Even if high availability features are not purchased the decision to use SAN might already be made and fail to be revisited after changes to the plan are made.\u00a0 It is very common, in my experience, to find projects of this nature with sometimes more than fifty percent of the total expenditure on the project being spent on products that the purchaser is unable to even describe the reason for having purchased.<\/p>\n This concept does not stop at virtualization.\u00a0 Extend it to everything that you do.\u00a0 Keep IT in perspective of the business and don’t assume that going with one technology automatically assumes that you must adopt other technologies that are popularly associated with it.<\/p>\n","protected":false},"excerpt":{"rendered":" I see this concept appear in discussions surrounding virtualization all of the time.\u00a0 This is a broader, more general concept but virtualization is the “hot, new technology” facing many IT organizations and seems to be the space where currently we see the “just because you can, doesn’t mean you should” problems rearing their ugly heads … Continue reading Just Because You Can…<\/span>