Citrix released NetScaler SDX about 18 months ago. It solves a real problem: “appliance sprawl.” Specifically, NetScaler SDX runs multiple NetScaler instances on a single purpose-built appliance. However, to a business unit, to application developers, to other network admins, to even the admin of one of the NetScaler instances, it looks as if each instance is still an individual, dedicated appliance.
Under the covers we use virtualization to achieve this. But we’ve implemented it in a way that overcomes all the things that networking pros hate about traditional server virtualization: compromising on performance, data plane isolation issues, management plane isolation issues, support models, etc.
Something that we’ve never really talked about – until now, that is – is that our underlying virtualization architecture was built to support not just NetScaler, but other networking services as well. Today we announced that we will open up the next generation of the NetScaler SDX platform.
Several partners are joining us in this initiative. This means that the next gen platform can be used as a platform for not just NetScaler, but key adjacent L4-7 networking services as well. Our joint customers can deploy best-in-class services from the leaders in next generation security and compliance, application visibility, and enterprise mobility while leveraging NetScaler SDX’s multi-tenant infrastructure and data center footprint to simplify the network.
The use cases for this are almost limitless. Things we see coming up repeatedly are:
XenApp/XenDesktop: consolidate multiple NetScaler instances, Cloud Gateway, Branch Repeater and AAA services from RSA and CSE Secure Systems.
Content and file sharing: consolidate NetScaler, ShareFile Enterprise StorageZones, and data loss prevention from Websense.
Enterprise mobility: consolidate NetScaler, Cloud Gateway, IP address management from BlueCat Networks, and mobile security from Aruba Networks to support “bring your own device” rollouts onto the enterprise network.
In every case, each service is fully isolated from the other. They get their own memory space, CPU resources and networking stack. So, there is logical separation between them, which is a good thing. And you don’t have to worry about one service “overrunning” another. Which is a better thing. However, while each service is logically separate, through a capability we’re adding to the SDX management plane called AppFormations, all the services supporting a given application can be managed collectively.
Today, deploying the various advanced networking services needed for a given application is pretty manual and error-prone. We all know how much time is spent racking various devices (or maybe provisioning individual VMs), cabling them together, mucking around with VLANs, and then running around trying to figure out why X can’t ping Y.
AppFormations simplify this process. For a given application, an AppFormation prescriptively defines:
- the various network services deployed for a given application
- how those services are interconnected
- how the rest of the network connects to the AppFormation
In essence, AppFormations provide as app-centric definition of the network services a given application requires. Today, this definition is scattered across various components. If it is centralized anywhere, it’s probably only in a network admin’s head. With NetScaler SDX and AppFormations, this network definition becomes explicit. It’s tremendously useful for control, and for automating deployment of the various L4-7 services an application requires.
And, this app-centric definition is useful beyond NetScaler SDX. There is a whole other emerging part of the network that also really needs to be app-centric. But that’s another topic.