The Application Boom: A Guide to Managing Company-Specific Applications
When managing the application delivery service of an off-the-shelf application like Microsoft Exchange, you can expect extensive support – from the application vendor, the Application Delivery Controller (ADC) vendor and all the professional forums across the Internet. QYBWBYG9DECS
But what about “home grown” company-specific applications? Who can advise the application admin or the network manager with the best ADC configuration for this proprietary application? In such cases, it’s imperative to have intuitive tools to manage all aspects of the application delivery service life cycle for that application. This includes everything from development to deployment and maintenance.
Development
When you need to research and develop the ADC configuration for your proprietary application yourself, you want to do it without including complicated commands, menus and sub menus. A good way to avoid such complicated details is to use self-designed wizards based on configuration templates with different building blocks, which are intuitive and easy to understand. Here are a few examples for such “easy to understand” configuration building blocks:
- Server load balancing, health checks, high availability (e.g. GSLB for disaster recovery site)
- SSL termination, compression
- Application redirections, high availability
- Web acceleration, performance monitoring
Using this configuration methodology with smaller building blocks can make it much easier to discuss application delivery services with application developers that don’t have to necessarily be familiar with specific ADC configuration terms.
The final ADC configuration will eventually consist of a combination of the above building blocks – each one small enough to manage and tweak, enabling a faster and simpler tailoring of the ADC service to the application. Moreover, once the development stage is completed, the configuration template can easily be used to move the application to the production environment, even if the production environment uses different parameters (i.e. different IP address space). Simply feed the template with the updated information.
Deployment
Moving from development to production often involves physically installing the application on a completely different environment, including its ADC service. While the development environment is usually smaller and can use a software-based ADC, moving to production requires higher capacity and performance, thus using a full-blown ADC appliance. This is why it is important to keep in mind full compatibility between different ADC form factors; it enables seamless migration from a dev environment to a production environment.
Deployment phase also introduces risks. Since it touches the production environment and can easily impact other running applications in production, any change to the ADC configuration can have an affect on other applications using the same ADC appliance. One way to eliminate such risks is to use fully isolated virtual ADCs per application, so when rolling out a new application into the production environment, you can promptly provision a new virtual ADC that is fully isolated and apply the new configuration template prepared in development, without any risk. A good ADC solution should give you the freedom to allocate and guarantee the exact resources required for each application – the amount of throughput, memory, compression and encryption resources required.
If your application requires implementation in different sites (e.g. for disaster recovery sites), you can easily use the template prepared to replicate the deployment.
Maintenance
Once your application has been deployed and is running, how can you tell if and when it’s providing the quality of service you expect? How do you know if all the functions your users are actually using are responding fast enough? The best way is to use Application Performance Monitoring (APM). However, this is usually considered too complex and expensive, especially if the application is deployed in multiple locations.
One option that not many application administrators are aware of is to use the ADC solution for application performance monitoring. It makes a lot of sense if you think about it. The ADC is the switchboard of all user and application transactions. It oversees any user requests and server responses. A good ADC solution will be able to collect information about your application performance and forward it to a dashboard, which alerts you if your application is out of its designated SLA.
What will you do if you discover that your application is simply too slow? If it’s because more resources are required (e.g. additional capacity within the servers, more throughput than anticipated, etc.) – this can easily be fixed. Simply add more servers and scale the capacity of your virtual ADC.
But what if the application performance problem is in the design itself? Does that mean the application needs to go back to the design board? Not necessarily. Some ADC solutions now offer automated tools for web performance acceleration that won’t require any code change in the application nor network configuration change or a client installation in the user side.
A homegrown application developed in-house can be tailored to bring the specific values and expertise of an organization to the end user and customers. On the other hand, the whole life cycle of the application – development, deployment, maintenance and optimization – must rely on the available tools and knowledge that exist within the organization. In such cases, it is important to use an ADC solution, which anticipates potential challenges and empowers the application team to provide the best functionality and user experience at minimal cost and effort.
