I own a car and drive it regularly. I keep it maintained according to a schedule and make sure it is running well. To ensure that vehicles are running properly, auto manufacturers introduced the on board diagnostics (OBD) standard. Since 1996, the OBD-II standard has been required on all vehicles in the United States and Europe has the EOBD equivalent.
OBD-II is a self-diagnostic and reporting capability. That little red or yellow light on your dashboard telling you that your vehicle needs to be serviced is based on this information. Recently, cars have added the ability to send detailed information directly to the manufacturer or other online monitoring applications to give real-time information to interested parties.
Diagnostics for application delivery
When we talk about application delivery, this monitoring and diagnostic capability is what matters most. Delivering applications in a fast, secure, and reliable manner does not matter if there is not the diagnostic capability to see the state of the application and provide insight as to why the application is behaving the way it does.
Most people do not care about the specific characteristics of their vehicle. The actual emissions levels of the exhaust, the exact ratio of the fuel:air mixture under certain driving conditions, or even the exact air pressure in their tires are not of interest as long as the vehicle reliably gets the person from point A to point B efficiently and consistently.
In a similar light, the network infrastructure has become less relevant when looking at application delivery. It is essential, just like the drive train in your car is necessary, but it is just a function that enables the application to perform. Ultimately, it is the application and the proper delivery of that application that end users and businesses care about.
Different metrics for different applications
We expect applications to perform within certain parameters. These measurable factors vary depending on the actual applications and their business value. Email is more important than surfing the Internet. Video conferencing has different performance requirements (bandwidth, latency, jitter) than the CRM.
We unconsciously assign application service level expectations based on the application and how it is applied within our business and personal routines. In reality, we need to be defining the criteria for these applications and what is expected for their service level assurance (SLA). Once we determine the actual application SLA, it becomes possible for us to create tools to provide the diagnostics necessary to monitor the current application performance.
If the application delivery is not within the SLA parameters, it becomes essential that one has the visibility to understand what is degrading the application performance. Only then, is it possible to know what needs to be done to remedy the problem and bring the application delivery infrastructure back to normal operating conditions.
It is not enough to provide application delivery controller (ADC) technologies to enable applications to be faster, more scalable, and more reliable. Just like the auto manufacturers discovered, it is critical and beneficial to have a system in place to provide the analytics and monitoring capabilities to ensure that your application SLA agreements are being maintained.
Frank Yue is Director of Solution Marketing, Application Delivery for Radware. In this role, he is responsible for evangelizing Radware technologies and products before they come to market. He also writes blogs, produces white papers, and speaks at conferences and events related to application networking technologies. Mr. Yue has over 20 years of experience building large-scale networks and working with high performance application technologies including deep packet inspection, network security, and application delivery. Prior to joining Radware, Mr. Yue was at F5 Networks, covering their global service provider messaging. He has a degree in Biology from the University of Pennsylvania.