Last week I spoke with Pam Baker, a writer with CIO Update, for an article titled The Top 5 Places to Use Virtualization. As you would expect from an experienced professional like Pam, it was a great article, with solid contributions from many others as well.
Pam specifically asked me to provide readers with advice on how to move into production with virtualization, and following our discussion published her article, including this section on â€˜Low Risk Servicesâ€™:
Move the easy stuff — Web servers, print servers, file servers, single-system applications, etc. — first. â€œCo-locating these environments on virtual machines delivers quick wins in business continuity, agility, resource efficiency, and of course cost savings — both cap-ex and op-ex,â€ explains Andi Mann, vice president of Product Marketing at CA Technologies Virtualization and Service Automation Business Unit. Moving low-risk services such as HR systems — file servers and Intranet applications, for example, but not payroll or e-mail — onto virtual machines is â€œa great next step into production virtualization.
However, I wanted to complete the thoughts I had while speaking with Pam, and address some of the other phases of virtualization deployment that we discussed.
What is the first service you should consider using virtualization?
Without doubt, application development is the very first place you should use virtualization. Dev/test â€“ including unit test, system test, quality assurance, and user acceptance â€“ is a great opportunity for virtualization because it is:
- Low-impact â€“ it never touches a customer or even an internal user directly, and so even if you make â€˜rookieâ€™ mistakes they cannot damage customer service.
- High-reward â€“ it allows applications to be developed, tested, and delivered both faster and cheaper, driving both agility and cost savings.
Plus, developers are already tech-savvy, so they can learn and deal with virtualization quickly and easily.
This is also a very strategic way to start, with a long tail of positive results. Applications developed on virtual servers can easily be deployed into production on virtual servers too. This gives you an easy route to production, with all the cost, continuity, and availability benefits that delivers.
At this stage you can also start to implement a â€˜virtual-firstâ€™ policy for new applications â€“ where every new service is deployed on virtual servers unless there is a clear business case â€“ along with authorization, and even additional chargeback penalties â€“ for requesting a physical server.
With this level of experience under your belt, you and your teams will quickly gain a broad, production-quality baseline of skills, knowledge, and ability to handle virtualization, while avoiding negative business impact as you acquire these capabilities in your teams.
This then establishes a solid â€˜base campâ€™ to launch the next phase of virtualization â€“ attacking existing production applications.
How can you move virtualization beyond the initial deployment?
Once you institutionalize virtualization in dev/test, and subsequent production deployments of new applications, as Pam noted in her article, you should look at moving existing low-risk/low-impact production services onto virtual servers next.
As I discussed with Pam, that will often mean virtualizing internal services, like your HR systems, file servers, or Intranet applications. However, just because they are internal systems, does not mean they are low-risk, or low-impact.Â That is why I said you should probably leave payroll and e-mail alone in this phase â€“ they are both not only high-risk, but also high-impact if anything fails.
Converting and migrating these low-risk, internal systems establishes another, higher-levelÂ â€˜base campâ€™ from which to expand your virtualization deployments. You can move to a broader virtualization deployment with greater confidence and lower risk, because you have the deeper experience.
Moreover, you have proven to the business how virtualization delivers incremental and substantial gains in CapEx reduction, OpEx reduction, agility, continuity, and time-to-market.
From there, you can then move into more complex, external-facing, mission-critical applications and services.
What are the best uses for virtualization?
Almost everything is a good use case for virtualization! Most organizations should be able to get 80-90% of their server workloads onto virtual machines â€“ far more than the 16% of workloads that analyst firm Gartner says is running in virtual servers today.
The â€˜low-hanging fruitâ€™ of virtualization is, as Pam wrote, the â€œeasy stuffâ€ like Web servers, print servers, file servers, and simple, single-system applications. Co-locating these environments on virtual machines delivers quick wins in business continuity, agility, resource efficiency, and of course cost savings â€“ both CapEx and OpEx.
Similarly, it is relatively easy to get new applications onto virtualization, by starting in development and test, and by implementing a â€˜virtual firstâ€™ policy for new applications.
But even most of the â€˜difficultâ€™ applications â€“ mission-critical, tier 1, OLTP, multi-tier, complex composite applications, etc. â€“ can be virtualized with the right approach. These applications will benefit greatly from the improvements to scalability, continuity, performance, and resource efficiency that virtualization delivers.
What are the worst use cases for virtualization?
While it is true that almost all services can and should be virtualized, it is also true that some services are not well suited for a traditional, multi-VM, shared-server virtualization deployment.
The worst use cases for virtualization are where application services saturate one or more physical resources. If, for example, an application regularly uses over 90% of available CPU, memory, or network bandwidth, then there is no headroom left over for another system or service to use these resources. This means that it is not a good option to co-locate this application on a virtual server that shares physical resources with another application.
Typically such services include:
- CPU intensive applications â€“ such as actuarial, modeling, design, or engineering applications
- Memory intensive services â€“ such as database systems, data mining, or business intelligence
- Network intensive services â€“ such as transaction processing or multi-user applications
Some services â€“ such as corporate e-mail servers â€“ may actually be all three.
However, you should never discount the benefits of deploying any application in a virtual server, even if it is deployed all by itself. Even if it will not provide hard ROI through hardware reduction, you can still gain major benefits in improvements to availability and continuity, operational costs, and ease of maintenance, by using virtualization.
How Did You Virtualize?
These are some ways to start with virtualization, some ways to expand virtualization, and some areas that you should probably leave until late in the cycle(if you virtualize them at all).
But I wonder where you started (or where you plan to start)? How did you expand beyond the low-hanging fruit? What types of services have you avoided virtualizing? Why?
Feel free to add your comments below. I would love to hear about your experiences.
(This entry has also been posted as an entry at CA.com – feel free to discuss there, or here)