Blog posted last week (/blogs/2011/09/19/using-published-application-template-know-the-workflow/) in this series focuses on simplified workflow for deploying published Application Templates. This blog will focus on taking you through the workflow of creating an Application Template from scratch.

The workflow for creating Application Templates takes you through the key logical steps which flow through the system. Here is a quick look through the involved workflow and understand the key functionalities and advantages at every step.

  

Step 1: Adding a Template can done with single click on the Application Template GUI where instead of importing you choose to add a new Template.

  

Step 2: Create the Application which is specifying the name of your application for which you want to define this template. Application name can be anything you define.

  

Step 3: Create Application units for the given deployment. I believe this is the most important piece where you need to logically create Application Units to ensure that you can distribute the App deployment based on type of content or requests or responses. This logical distribution is the key which enables you to define all those L7 feature policies to take respective actions on content for various Application Units. These policies/actions/profiles are local to Application Unit and it does not interfere with traffic being processed by other Application Units. With this logical distribution you can achieve better performance, response time, security and stability for your application deployment.

Definition of these Application Units is created based on the Rule which defines how the traffic should be distributed towards this application unit. In this example all the requests having “frontpage” token in request URL would be pointed towards “FrontPage” application unit. Similarly you define other Application Units based on respective rules which define the flow path of requests towards the backend servers. How are we going to ensure that all the requests would be taken up by one or the other Application Unit? Interestingly there can be requests which may not fit into any of the rules defined by the Application Units and they all are directed towards catch-all Application Unit called “default”. Thus in any case the requests are going to be taken up by system and will get processed by backend Application.

Step 4: Configure public endpoint which is where all Client traffic terminates. This is the IP address which is seen externally and is used for communicating with end clients. This is the point where we evaluate all those rules and define path for client requests to follow. All the Application Units have no real IP address as they are not in the real path of communication. They are more like logical points which own the L7 processing for application based on type and nature of content.

You can choose one of the existing endpoint or also create new endpoint for your application. The endpoint always remains as UP and then you start associating those Application Units with this endpoint. The “default” application unit will also be associated to same endpoint. Remember a deployment can have many Application Units but only 1 endpoint in any case.

Step 5: Configuring backend services for the application which are actual representation of the internal server side resources. This is key information which is to be provided and if there are logically separated backend services then you must take care of appropriately binding them to respective application units. For a large application deployment it is always good to have servers with different type of content mapped to application units such that they get to process specific type of requests.

 

Step 6: Feature configuration is the core value which Application Template provides for application deployment. There are various useful features on Layer 7 stack in NetScaler which provides acceleration, optimization and security for your application deployment. Being able to understand the key requirements for you application and accordingly configuring these features is a key. All these feature modules are aligned to application units such that traffic which gets impacted is limited to that application unit visibility. The core features available are:

  • Compression – optimization, bandwidth savings
  • Caching – optimization, bandwidth and processing savings on server side
  • Rewrite – content modification on the fly
  • Filter – Filtering out the requests before they reach server
  • Responder – Filtering the requests and generating intelligent response from NetScaler
  • Application Firewall – securing your application with positive and negative security

 

 Six steps and you are done building application environment through NetScaler Application Templates 🙂