I guess these are the times for virtualizing SSL VPN and WAN optimization appliances in the industry. After we launched and shipped Branch Repeater VPX and Access Gateway VPX virtual appliances, one of our competitors followed suit and announced their WAN optimization virtual appliance.
The market buzz on virtual appliances has raised frequent questions about the similarities and differences between ‘network virtual appliances’ and ‘virtualized platforms or environments’.
What are ‘virtual appliances’ and ‘virtualized platforms (aka virtualized environments)’? Without trying to craft a definition that deserves a place in the Merriam-Webster’s dictionary, I will try to explain this in a way that most customers and partners have understood it.
Virtual appliance is an all-software solution that customers take and ‘deploy’ it on “their” existing servers, i.e., customers deploy virtual appliances on their own off-the-shelf industry-standard hardware. Virtualized platform/environment, on the other hand, is still a proprietary hardware solution that customers take and deploy their other applications on to that proprietary hardware, i.e., customers deploy their other apps on the networking vendors’ proprietary hardware rather than onto their own off-the-shelf industry-standard hardware.
So why should a customer care? In the end, aren’t the benefits the same?
Both virtual appliances and virtualized platforms offer the benefits of hardware consolidation, and thereby benefits of efficient power and energy management. You can deploy your virtualized apps on either of them with similar benefits. However, you may want to verify with your networking vendor if any virtualized apps are NOT supported on their virtualized platform. And this is where the similarities end. Here are some questions you should ask before evaluating virtual appliances and virtualized platforms.
- What is the underlying or embedded hypervisor on the virtualized platform? Can I leverage my existing virtualization tools and expertise for remote management? Typically, vendors of virtualized platforms put a hypervisor on their own proprietary hardware; they may then put a shim interface on top of the underlying hypervisor and require customers to use closed and proprietary APIs/interfaces to deploy other virtual apps onto the virtualized platform. Often these other virtual apps are not directly interfacing with the underlying hypervisor. Since the underlying hypervisor is not fully supported by the vendor and exposed to customers, customers cannot fully leverage their existing virtualization tools and expertise for managing the virtualized infrastructure.
- What other and how many virtualized apps can I deploy on the virtualized platform? With a true virtualization solution, customers can deploy any virtualized application and any number of them – only limited by the size and resources of the underlying server platform. Industry-standard off-the-shelf servers come in a large variety of sizes and configurations – further expandable by adding off-the-shelf memory/disk/network cards. On the other hand, virtualized platforms come in a small number of fixed hardware configurations, with limited expandability if any. Unless your needs for hardware resources and number of virtualized apps match exactly with the proprietary hardware of the virtualized platform, you will limit your ability to fully leverage the benefits of virtualization because you are not truly decoupling your virtualized apps from the underlying hardware.
- More importantly, what apps can’t be deployed on the virtualized platform? Can the vendor certify and support any application on their virtualized platform? Leading hypervisors today support almost any virtualized application. However, vendors of virtualized platforms typically add their own shim on top of the underlying hypervisor, forcing customers to deploy on the platform only those virtualized apps that the vendor have certified (usually a small limited number compared with what the underlying hypervisor supports). Make sure to ask the vendor how they will resolve your support issues – will the vendor ask you to work with both them and the hypervisor vendor separately? Alternatively, can you just call the virtualized platform vendor for technical support and will the vendor transparently work with the hypervisor vendor to resolve your issues?
- Can I leverage my current training and skilled IT staff who are already experts at managing and administering current hardware servers? Check with virtualized platform vendor if you need to train your IT staff on any new management, configuration, troubleshooting or reporting tools and APIs ─ in addition to those of the underlying hypervisor that you may have already trained your staff on.
- How do I design and implement a common HA or failover solution for most, if not all, of virtualized apps and virtualized hardware? Can I include the virtualized platform in the available pool of virtualized hardware? One of the promises of true virtualization is flex capacity – the ability to add more servers or remove servers from your pool of active virtualized servers. Often, you may not be able to treat the virtualized platform as any server for pooling purposes. For example, can you migrate the WAN optimization workload to another available server in the pool?
- Can I repurpose the virtual platform for other uses in the future? Although the virtualized platform seems to appear like any virtualized server, they cannot be pooled with other industry-standard servers. Nor can they be repurposed for other uses later.
- What are the supply chain/procurement implications of hardware servers and appliances from different vendors? Can I select the hardware platform of my choice based on my needs from my preferred hardware vendor? Many customers like to streamline their supply chain and procurement operations, reducing the number of suppliers they rely on. With fewer strategic hardware suppliers, customers are often able to better leverage volume discounts from their strategic suppliers, while simultaneously streamlining and reducing the costs of their supply chain and procurement operations.
- Am I paying a markup on the virtualized platform, which is already marked up by the networking vendors to cover their OEM costs of sourcing from the big hardware vendors? Since a virtualized platform is not a true virtual appliance, the vendor often pays a markup to their hardware OEM vendor/supplier. To maintain their margins, the vendor then charges a markup to their customers. Customers should consider whether they get a better hardware value and price by procuring the industry-standard servers directly from the big hardware vendors such as HP, Dell or IBM.
- Can I get hardware replacement parts immediately if the hardware breaks in any remote office or branch, in any corner of the world (not just in the US or near major metropolitan areas)? This is a question I often hear from those who are considering WAN optimization solutions. Many customers have branch offices in far corners of the world, or even far corners of a country. The major server vendors – HP, Dell or IBM – are more likely to have services or parts offices in more remote locations worldwide than any of the pure-play WAN optimization vendors today. This is especially important for those customers who leverage and rely on far-flung branch offices that are closer to talent pools and their customers. Such branch offices can’t afford to wait several days or weeks to get a replacement for that broken power supply or hard disk.
Rather than provide a virtualized platform for consolidating servers and apps on proprietary hardware servers, virtual appliances run on industry-standard servers, offering a more flexible and cost-effective solution than proprietary virtualized platforms.Why not start today and try it for yourselves – at no cost, yes, FREE ─ by visiting http://www.citrix.com/trybranchrepeater?