Will Citrix ship their networking products only as appliances?
Going over the recent Synergy announcements and other discussions I’ve had with product experts it got me thinking what the Citrix networking range of products (Netscaler, Branch Repeater, Access Gateway, Open Cloud Access) might look like in a few years time.
Here’s a bold prediction:
Citrix networking products will eventually only be available as virtual appliances.
Lets examine why this would make sense.
Citrix are modularising their products
Netscaler has always been modular in the fact the same hardware device can run different editions of Netscaler software depending on which license you’ve purchased. Newer releases of the VPX appliance are licensed by consumption rather than features. Imagine being able to run a Netscaler, Branch Repeater and OpenCloud solution on the same piece of commodity hardware on your chosen hypervisor. Want to add a CAG? Fine – just import the CAG VM onto your existing kit.
Don’t have an existing hypervisor? No problem, Citrix will ship a fully supported Netscaler+XenServer installation you can install onto your hardware.
Citrix are moving to a common code base for their products
Take Access Gateway- Citrix will be able to run this on native CAG hardware, Netscaler hardware, and virtual appliances. If all platforms (apart from Hyper-V and ESX/VSphere) can be provided by utilising the Xen kernel this cuts down the number of platforms the code needs to support.
The Access Gateway v5 is being modularised so it can be run on both legacy CAG hardware and existing Netscaler hardware.
Citrix core strength isn’t hardware
Having to maintain relationships with different hardware manufacturers/vendors is time consuming and costly. Shipping tin is not one of Citrix’ core strengths – they are a software company. Today Citrix (and their customers) have three possible hardware devices : CAG (former Net6), Netscaler and Branch Repeater (formerly WANScaler)
If Citrix can provide a HCL for their networking products (via the XenServer HCL plus minimum hardware specifications) and be a purely software vendor that moves the whole hardware design/procure/support/repair onto someone else’s plate. Citrix could partner with a HP or Dell or even Cisco to recommend suitable off-the-shelf hardware to support the required throughput, and even offer support contracts with the relevant product support services if customers didn’t already have some kind of hardware support agreement in place.
If customers just want to use their existing Virtual Infrastructure platform, great. Citrix already supports this model today via their VPX appliances.
Let the hypervisor handle HA
Citrix will no longer need to spend as much time writing HA code into each individual product. Let the hypervisor provide the HA that best suits the customers requirement. Simpler code, fewer bugs resulting in enhanced reliability.
True elastic capacity
It’s far easier to add resources to a VM (cpu/memory) and spin up new VMs than it is to buy another appliance and get it racked & stacked in your data centre. Cloud providers wanting to do multi-tenant installations can provision lots of smaller virtual instances, rather than carve up a large, expensive device.
If your data centre is in the cloud, you don’t have (and need) hardware
Cloud providers already have data centres chocked full of their preferred flavour of hardware. They just need the features Citrix provide in their software. If more and more companies start using cloud providers to host their infrastructure, the demand for kit on customers own sites will plummet. As demand for hardware decreases, costs increase due to lower production runs, eventually making it uneconomical to continue to sell hardware devices.
Improving hypervisor network I/O
Technologies such as Intel SR-IOV are allowing hypervisor network I/O to reach previously unheard of levels. With the massive network I/O required by Netscalers and Branch Repeaters, such emerging technology would allow appliances to access the full capability of the hardware without having to be running directly on the tin like todays boxes.
Much lower start-up costs
Committing to buy a bunch of devices is expensive, especially if you don’t need all the capacity they provide from day one (but you need the ability to ramp up capacity on expand, so need the higher-spec boxes which cost more) . Being able to deploy virtual instances, starting small, on commodity hardware, and then ramping up VM resources, and your license to match demand makes much more financial sense and delivers true utility computing.
What are the challenges?
No hardware encryption
Netscaler devices contain dedicated hardware designed to perform fast encryption and decryption for the SLL offload engines. Commodity hardware would not contain this, so would need addition CPU resources allocating to achieve anywhere near comparable performance as the current hardware.
Commodity hardware can be expanded with hardware-encryption capabilities via PCI cards but this would need to be accessible through the Xen hypervisor, very much like the pass-through GPU and SR-IOV networking work being done.
No fail-to-wire NIC
WANScaler devices usually sit in-line between WAN routers and your LAN. To prevent loss of connectivity if the device, or NIC fails, they are equipped with special “fail-to-wire” NIC adaptors which turn into a piece of cable if on failure.
These NICs are not generally available for commodity hardware, so you would lose this fail-to-wire functionality, and risk a potential network outage should the virtual appliance or hypervisor fail, hang or develop a hardware fault. Some of this might be mitigate by the HA features of the hypervisor, but networking and routing is complex, and whether one could achieve the same level of “fail safe” as a fail-to-wire hardware NIC remains to be seen.
What do you think?
Post your thoughts and comments.
2 Comments
Leave a commentTrackbacks and Pingbacks
Leave a comment
You must be logged in to post a comment.
Good article!
Was never a fan of the hardware solutions, because of redundancy, high costs, warranty etc etc.
But the fail-to-wire makes a good point, they might solve that by using the virtualswitch, even difficult networking would be able to switch from one box to another. Or a real FT solutions would be nice! (buy Marathon, and let them make a good linux FT solution!)