Ah, those were the days, weren’t they? When you needed a way to inspect data at the edge for application-specific issues but knew that implementing a solution capable of that kind of agility was more than likely going to end up with poor performance and angry users. When you needed to add something to secure applications and the network against the growing wave of attacks but knew that doing so would negatively impact performance.

It was a tough choice, and most people ended up going the route of maintaining application performance at the expense of security and optimization because the choice was really not a choice at all.

Remember how you sat and mapped out the architecture and tried to explain why it was that as the choices number of solutions deployed to address security and optimization and acceleration increased that performance decreased and they said they wanted it all? And you had to go back to your desk and shake your head because there was no single solution capable of addressing the problems in your application architecture without negatively impacting performance.

Remember the drain on the budget? Yeah, I remember that, too. Your budget was already limited and yet you needed to be able to ensure that applications were secure and fast and that you had a way in which you could address whatever might arise in the future, even though you had no way of knowing what that might be. The solution you wanted was agile itself, capable of being customized and extended so you didn’t need to acquire yet another solution platform when the next bottleneck, the next vulnerability, the next application problem was discovered. But you didn’t want to sacrifice performance, so you had to force-fit solutions into your architecture, often deploying them in configurations that were less impactful on performance but did not allow them to actually accomplish the task they were designed for.

Those were the days of niche application networking products; of single solutions aimed at addressing specific pain points like poorly performing applications, insecure platforms and applications, and less than optimally performing networks. When deploying a solution capable of network-side scripting to enable you and your security folks to address vulnerabilities and application-specific quirks in a centralized, optimized manner necessarily meant that you were introducing a choke point into the infrastructure that would impede performance.

Those were painful days, when the choices you had were really no choice at all.

Aren’t you glad those days are (almost) over?

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share