If it is, you might want to reconsider how you’re handling security, acceleration, and delivery of your applications before users “go postal” because of poor application performance.

Sometimes wisdom comes from the most unexpected places. Take Jason Rahm’s status update on Facebook over the holidays. He’s got what is likely a common complaint regarding the delivery model of the US postal service: the inefficiency of where postage due is determined. Everyone has certainly had the experience of sending out a letter (you know, those paper things) and having it returned a week or more later with a big stamp across it stating: Returned – Postage Due.

As Jason points out, the US postal service doesn’t determine whether postage may be due or not until the package arrives at its destination. If the addressee isn’t willing/able to pay that postage due, the package is of course returned via the delivery service, which incurs round-trip costs of transportation and handling at every point along the way.

If this sounds anything like your application infrastructure architecture, then you might want to reconsider how you’re handling the delivery of applications and where you’re applying policies that may affect the delivery process.

Every architecture has them: strategic points of control. These are points at which decisions can – and should – be made regarding the delivery of applications. Such points of control range from routing to admission control (security and identity management functions) to application-specific authorizations. There are myriad policies that govern access to and delivery of applications and each one is most efficiently applied at a different point in the infrastructure. If every function – admission control, delivery optimization, application  authorization – is applied at the application, it leads to a postal service architecture in which the same costs (both monetary and in performance) are incurred for every request and response, regardless of whether they were actually fulfilled or even legitimate requests.

If the postal service were cost conscious, they’d examine the package at the first strategic point of control based on the destination and the package variables and there determine how much it would cost before it ships that happy box of caffeine off only to be returned – days or weeks later – for lack of proper postage that it should have been able to determine in the first place.

The postal service – and you – likely have all the data available at the first point of entry into your application to determine whether the request is legitimate and what optimizations need to be applied before  the package enters “the delivery system”, a.k.a. the infrastructure. Incurring costs associated with processing, storage, and risk by processing what could have already been detected as malicious or illegitimate seems a terrible waste of infrastructure on the scale of the waste associated with the postal service.

Why apply compression to data on the application server when that data may need to be examined by other components in the architecture on the way back to the user and may, in fact, degrade performance rather than improve it? Why not apply compression at the last point possible; at the strategic control point that sits between your infrastructure and the “rest of the world”, i.e. the user and their network. Why are requests not examined at the first possible strategic point of control for validity? Why allow what is potentially a dangerous and malicious request pass through the infrastructure so it can be processed by every component in the architecture and potentially wreak havoc throughout the data center? Why not examine the request at the first possible point and accept or reject it before the costs associated with that processing and the risks are incurred by the organization?

All this additional processing on what are illegitimate and malicious requests places a burden on the entire infrastructure and, especially in the case of web and application servers, that burden can translate into reduced performance for legitimate users as well as additional costs in the form of unnecessary increases in resource capacity required to support both illegitimate and legitimate requests.

You can’t eliminate all the costs, of course, but you can significantly reduce them when you apply application delivery policies at the most strategic point in your architecture possible. That means web application and e-mail scrubbing at the outer edges of your network, preventing spam and illegitimate requests from using up bandwidth and processing power on network, application network, storage, and application infrastructure. It means a reduction in the size of your logs, which makes correlation and reporting easier, faster, and less of a chore for IT personnel who must comb through gigabytes of data daily looking for needles in haystacks to help application developers track down errors in application code. It means reducing the overall costs associated with delivering applications to user and improving the performance and reliability of your entire architecture.

Very few IT architects would point to the US postal service as an ideal model of delivery. So if your infrastructure looks anything like the postal service, maybe it’s time to take another look at how you’re applying policies and processing requests and make some modifications to a more cost-effective, efficient service delivery model. 

Related blogs & articles:

• Botnets, Worms, and “Open” Clouds: Can Enterprise-Class Clouds Be Far Behind?
• ‘Drowsy’ Networking
• WARNING: Security Device Enclosed
• The Application Delivery Spell Book: Detect Invisible (Application) Stalkers
• When Is More Important Than Where in Web Application Security
• Web Application Security at the Edge is More Efficient Than In the Application
• If Your Users See an HTTP Error Code You’re Doing It Wrong
• JSON versus XML: Your Choice Matters More Than You Think
• The Cloud Computing – Application Acceleration Connection