We know NetScaler belongs to the segment called ADC, the Application Delivery Controller segment. What’s new about it? Now the question to ask is how many times we have deployed NetScaler from Application point of view than as a network appliance? If NetScaler belongs to ADC which is meant to control overall Application delivery, why we look at it from network view point more often than Application view point? There are multiple such questions and good history behind it as why an Application is just a service or combination of IP+Port+Protocol etc. The simple reason is that looking at NetScaler as a network appliance with some amount of Application aspect worked for many years in the past.
This line of thinking needs to change as Applications are not just about a service running over http/https. Applications are getting complex with all new features and capabilities and Application content today has got mix of everything possible and valid. The growth of Web as Web2.0 and Cloud/SaaS apps have changed the game where most of the business logic now resides within application and NetScaler as an ADC needs to handle this traffic very carefully. This could mean selective compression of content, intelligent caching of responses, attribute based transformation, dynamic profiling and securing of the application traffic, centralized authentication and authorization. Thus transformation has to happen in a way that an Application owner can successfully configure NetScaler appliance without needing help from network guys. The whole system and configuration around various buckets need to transform in a way that it just makes sense for the Application owner. This will be the path on which we need to walk to ensure that NetScaler’s core value set is around applications.
“Configuring a device” is the wrong place to start, because this is exactly what the applications person does not want to do. An app owner wants to deal with service constructs, and abstractions of policies, which might at the end of the day, be operationalized as network level configuration, but is never visualized or constructed as such. This is something that the NetScaler team recognized years ago – when we walked down the path of designing AppExpert Application Templates. Our approach to this degree of abstraction dates from the early days of 2005, when we provided a policy infrastructure that was deterministic in nature, allowing people with a reasonable degree of proficiency with network level constructs and app level patterns, to create rules – to identify a traffic subset, and apply a sequence of actions to that traffic. There was still a “Reasonable” degree of network expertise that was required, and while we received much kudos from customers who appreciated our effort to simplify the mundane task of configuration, we continued seeing requests from application administrators who wanted yet more abstraction…
Then came 2007, where we introduced the Application Templates – the configuration abstraction that made it possible to visualize an application’s set of components, articulate through drag-and-drop type of interface the various actions to be taken on those components – caching, compression, transformation, redirection, application firewalling, DDoS protection etc, in a way that allowed for decomposition of duties. Imagine this sequence of events – where the NetScaler is racked up by an operations team, IP’ed, and delegated access is provided to an application owner/ admin – who connects to the Citrix community site, downloads a template for one of the popular packaged applications (or a generic template, with the most common policies applicable for a web application – allowing for rapid customization) imports that into the NetScaler, visualizes the various policy attributes and actions, and hands off to the server operations team that actually has the resources from where those applications are served. The server operations team then applies a set of IP addresses and ports, that describe the end points from where the application is served, the end-user facing IP address that the DNS servers for that application point to – and voila – the application is ready to be delivered – secure, optimized, and highly available.
Evolutions in this model have led to the ability to carry over this process across the entire application lifecycle, across development, testing, staging, production, with analytics or performance, response times, audit etc. Fundamentally then – we have a demonstrated way of application configuration abstraction from network level configuration policies, a way to easily share and author new abstractions, apply them across various phases of an application lifecycle, and maintain complete control/ security with delegation – where the person best meant to perform a task, performs that task. With introduction of Application Firewalling capabilities through Application Template in last release we closed all the gaps on security front with the positive and negative security models working on respective logical points.
Lots of history and lessons learned throughout 🙂 . This particular topic excited me recently with some key announcements made by our friends in this space. Those announcements made me realize that this is something we thought and implemented long back, now we just need to spread the awareness. Thus here is a series of blog posts which will take us through the end to end experience with Application Templates in their current form factor.
Provide us the feedback and your experience on this topic.