In speaking with small business IT professionals, one of the key factors for hesitancy around deploying virtualization arises from what is described as “don’t put your eggs in one basket.”<\/p>\n
I can see where this concern arises.\u00a0 Virtualization allows for many guest operating systems to be contained in a single physical system which, in the event of a hardware failure, causes all guest systems residing on it to fail together, all at once.\u00a0 This sounds bad, but perhaps it is not as bad as we would first presume.<\/p>\n
The idea of the eggs and baskets idiom is that we should not put all of our resources at risk at the same time.\u00a0 This is generally applied to investing, encouraging investors to diversify and invest in many different companies and types of securities like bonds, stocks, funds and commodities.\u00a0 In the case of eggs (or money) we are talking about an interchangeable commodity.\u00a0 One egg is as good as another.\u00a0 A set of eggs are naturally redundant.<\/p>\n
If we have a dozen eggs and we break six, we can still make an omelette, maybe a smaller one, but we can still eat.\u00a0 Eating a smaller omelette is likely to be nearly as satisfying as a larger one – we are not going hungry in any case.\u00a0 Putting our already redundant eggs into multiple baskets allows us to hedge our bets.\u00a0 Yes, carrying two baskets means that we have less time to pay attention to either one so it increases the risk of losing some of the eggs but reduces the chances of losing all of the eggs.\u00a0 In the case of eggs, a wise proposition indeed.\u00a0 Likewise, a smart way to prepare for your retirement.<\/p>\n
This theory, because it is repeated as an idiom without careful analysis or proper understanding, is then applied to unrelated areas such as server virtualization.\u00a0 Servers, however, are not like eggs.\u00a0 Servers, especially in smaller businesses, are rarely interchangeable commodities where having six working, instead of the usual twelve, is good enough.\u00a0 Typically servers each play a unique role and all are relatively critical to the functioning of the business.\u00a0 If a server is not critical then it is unlikely to be able to justify the cost of acquiring and maintaining itself in the first place and so would probably not exist.\u00a0 When servers are interchangeable, such as in a large, stateless web farm or compute cluster, they are configured as such as a means to expanding capacity beyond the confines of a single, physical box and so fall outside the scope of this discussion.<\/p>\n
IT services in a business are usually, at least to some degree, a “chain dependency.”\u00a0 That is, they are interdependent and the loss of a single service may impact other services either because they are technically interdependent (such as a line of business application being dependent on a database) or because they are workflow interdependent (such as an office worker needing the file server working in order to provide a file which he needs to edit with information from an email while discussing the changes over the phone or instant messenger.)\u00a0 In these cases, the loss of a single key service such as email, network authentication or file services may create a disproportionate loss of working ability.\u00a0 If there are ten key services and one goes down, company productivity from an IT services perspective likely drops by far more than ten percent, possibly nearing one hundred percent in extreme cases.\u00a0\u00a0 This is not always true, in some unique cases workers are able to “work around” a lost service effectively, but this is very uncommon.\u00a0 Even if people can remain working, they are likely far less productive than usual.<\/p>\n
When dealing with physical servers, each server represents its own point of failure. \u00a0So if we have ten servers, we have ten times the likelihood of outage than if we had only one of those same servers. \u00a0Each server that we add brings with it its own risk. \u00a0If each failure has an outage factor of 2.5 – that is financially impacting the business for twenty five percent of revenue for, say, one day then our total average impact over a decade is the equivalent of two and a half total site outages. \u00a0I use the concept of factors and averages here to make this easy, determining the length of an average outage or impact of an average outage is not necessary as we only need to determine relative impact in this case to compare the scenarios.\u00a0 It’s just a means of comparing cumulative outage financial impact of one event type compared to another without needing specific figures – this doesn’t help you determine what your spend should be, just relative reliability.<\/p>\n
With virtualization we have the obvious ability to consolidate. \u00a0In this example we will assume that we can collapse all ten of these existing servers down into a single server. \u00a0When we do this we often trigger the “all our eggs in one basket” response. \u00a0But if we run some risk analysis we will see that this is usually just fear and uncertainty and not a mathematically supported risk. \u00a0If we assume the same risks as the example above our single server will, on average, incur just a single total site outage, once per decade.<\/p>\n
Compare this to the first example which did the damage equivalent to two and a half total site outages – the risk of the virtualized, consolidated solution is only forty percent that of the traditional solution.<\/p>\n
Now keep in mind that this is based on the assumption that losing\u00a0some<\/em> services means a financial loss greater than the strict value of the service that was lost, which is almost always the case. \u00a0Even if the service lost is no more than the loss of an individual service we are only at break even and need not worry.\u00a0 In rare cases impact from losing a single system can be less than its “slice of the pie”, normally because people are flexible and can work around the failed system – like if instant messaging fails and people simple switch to using email until instant messaging is restore, but these cases are rare and are normally isolated to a few systems out of many with the majority of systems, say ERP, CRM and email, having disproportionally large impacts in the event of an outage.<\/p>\n So what we see here is that under normal circumstances moving ten services from ten servers to ten services on one server will generally lower our risk, not increase it – in direct contrast to the “eggs in a basket” theory. \u00a0And this is purely from a hardware failure perspective. \u00a0Consolidation offers several other important reliability factors, though, that can have a significant impact to our case study.<\/p>\n With consolidation we reduce the amount of hardware that needs to be monitored and managed by the IT department. \u00a0Fewer servers means that more time and attention can be paid to those that remain. \u00a0More attention means a better chance of catching issues early and more opportunity to keep parts on hand.\u00a0 Better monitoring and maintenance leads to better reliability.<\/p>\n Possibly the most important factor, however, with consolidation is that there is significant cost savings and this, if approached correctly, can provide opportunities for improved reliability. \u00a0With the dramatic reduction in total cost for servers it can be tempting to continue to keep budgets tight and attempt to purely leverage the cost savings directly. \u00a0 Understandable and for some businesses this may be the correct approach.\u00a0 But it is not the approach that I would recommend when struggling against the notion of eggs and baskets.<\/p>\n Instead by applying a more moderate approach keeping significant cost savings but still spending more, relatively speaking, on a single server you can acquire a higher end (read: more reliable) server, use better parts, have on-site spares, etc. \u00a0The cost savings of virtualization can often be turned directly into increased reliability further shifting the equation in favor of the single server approach.<\/p>\n As I stated in another article, one brick house is more likely to survive a wind storm than either one or two straw houses.\u00a0 Having more of something doesn’t necessarily make it the more reliable choice.<\/p>\n These benefits come purely from the consolidation aspect of virtualization and not from the virtualization itself. \u00a0Virtualization provides extended risk mitigation features separately as well. \u00a0System imaging and rapid restores, as well as restores to different hardware, are major advantages of most any virtualization platform. \u00a0This can play an important role in a disaster recovery strategy.<\/p>\n Of course, all of these concepts are purely to demonstrate that single box virtualization and consolidation can beat the legacy “one app to one server” approach and still save money – showing that the example of eggs and baskets is misleading and does not apply in this scenario. \u00a0 \u00a0There should be little\u00a0trepidation\u00a0in moving from a traditional environment directly to a virtualized one based on these factors.<\/p>\n It should be noted that virtualization can then extend the reliability of traditional commodity hardware providing mainframe-like failover features that are above and beyond what non-virtualized platforms are able to provide. \u00a0This moves commodity hardware more firmly into line with the larger, more expensive RISC platforms. \u00a0These features can bring an extreme level of protection but are often above and beyond what is appropriate for IT shops initially migrating from a non-failover, legacy hardware server environment.\u00a0 High availability is a great feature but is often costly and very often unnecessary, especially as companies move from, as we have seen, relatively unreliable environments in the past to more reliable environments today.\u00a0 Given that we have already increased reliability over what was considered necessary in the past there is a very good chance that an extreme jump in reliability is not needed now, but due to the large drop in the cost of high availability, it is quite possible that it will he cost justified where previously it could not be.<\/p>\n In the same vein, virtualization is often feared because it is seen as a new, unproven technology. \u00a0This is certainly untrue but there is an impression of this in the small business and commodity server space. \u00a0In reality, though, virtualization was first introduced by IBM in the 1960s and ever since then has been a mainstay of high end mainframe and RISC servers – those systems demanding the best reliability. \u00a0In the commodity server space virtualization was a larger technical challenge and took a very long time before it could be implemented efficiently enough to make it effective to use in the real world. \u00a0But even in the commodity server space virtualization has been available since the late 1990s and so is approximately fifteen years old today which is very far past the point of being a nascent technology – in the world of IT it is positively venerable. \u00a0Commodity platform virtualization is a mature field with several highly respected, extremely advanced vendors and products. \u00a0The use of virtualization as a standard for all or nearly all server applications is a long established and accepted “enterprise pattern” and one that now can easily be adopted by companies of any and every size.<\/p>\n Virtualization, perhaps counter-intuitively, is actually a very critical component of a reliability strategy.\u00a0 Instead of adding risk, virtualization can almost be approached as a risk mitigation platform – a toolkit for increasing the reliability of your computing platforms through many avenues.<\/p>\n","protected":false},"excerpt":{"rendered":" In speaking with small business IT professionals, one of the key factors for hesitancy around deploying virtualization arises from what is described as “don’t put your eggs in one basket.” I can see where this concern arises.\u00a0 Virtualization allows for many guest operating systems to be contained in a single physical system which, in the … Continue reading Virtual Eggs and Baskets<\/span>