Application Fluency: Networking Focused on Apps, Not Bits

By: Colin Walker

Editor’s Note: Occasionally, Enterprise Networking Planet is proud to run guest posts from authors in the field. Today, Colin Walker of F5 Networks discussions the concept of application fluency and why it matters to networking pros.

When you hear the term “application fluency,” what comes to mind?

It likely depends on your background. If you’re from the software world, “application fluency” might conjure up images of code with which you are deeply comfortable—an app with which you can flip bits to and fro, changing the way it functions, adapting to user input and needs in real time. If you’re a networking type, it might bring to mind a flexible network, bending and tuning to better support an application based on metrics, polling, and feedback from the app tier.

Me? I’m greedy. I picture both.

Regardless of your background, the core concept of application fluency is the same: Understand the application in its entirety. That’s it, really. It’s a simple concept, but it’s not easy.

Application fluency

Application fluency requires an understanding of how protocol, behavior, and network variables combine to affect the performance, security, and availability of an application.

The task of understanding an application runs both deep and wide. Deep because it requires the ability to dig through application data, user traffic, and behavior to a truly granular level to pull apart transactions, responses, statuses, and more with such detail that you can grasp what is going on at any moment. Wide because it requires understanding the application itself, its functions, the expected behavior, how it responds to issues, what those issues might be, and more.

Beyond this, application fluency requires understanding the user, the network, and the entire application flow. What are users requesting? Why are they requesting it? Where are they coming from? How many data centers and servers are there? Which ones respond to which pieces of the application? What’s the health of each system? How does system health vary or respond to load? To attacks? What protection mechanisms are in place to stop L4 attacks? L7? How do attacks affect the application? What is the rollout procedure for new code? How often does that occur?

And that’s just the beginning.

To legitimately be described as application-fluent, a device needs to be able to understand and account for all of these things and master many moving pieces. At the very least, the device must be able to see, understand, act, and react to anything crossing the network that might affect the application. Let’s look at each of these.


It sounds like a no-brainer, but “seeing” the app is harder than it sounds. Just how much can the device see? Every request from every user and every response from every server? Can it see bi-directionally? Can it do this at the speeds required by the app without becoming a bottleneck? What can it do with packets as they pass by? Can it log, sort, and store them? If the device isn’t at the right place in the network, chances are it can’t. Even if it is placed appropriately, it doesn’t necessarily see traffic in a fluent fashion.


A device that can’t dig through every shred of the application flow and recognize it as more than just network traffic can’t do much at an application level.  Any application developer will tell you they are far less concerned about bits in and out than they are about the session. They’re far more interested in a device that’s able to categorize and catalog those sessions into things like user usage patterns and personas, or success/fail rates per application function, per region, per release. (Have you seen a network monitor page for that? Me neither.)

The leap from merely seeing data on the wire to understanding an application’s functionality and usage is dramatic and powerful. Once you know what an application is doing and how it behaves, given the right tools, you can build logic statements around that usage. That’s when things really start to get interesting.

Act and React

Until a device can assert itself as part of the application flow, it’s merely a clever observer. While logging and charting are powerful in their own right, an application-fluent device can do far more. It can take action. It can intercept an error, decide what kind of error it is, make a logical decision, and find a server that can provide the appropriate response based on the client request. It can do that since it knows what the request was and what type of response should be returned. 

Application developers should be able to extend applications onto the network layer without having to build particular pieces of business logic into the application. A truly app-fluent device enables them to do this. It can make decisions and take action at wire speed, across hundreds or thousands of devices, for potentially millions of user sessions simultaneously, for hundreds of applications, each with its own unique needs, expectations, and behaviors.

Can your device handle that? If not, perhaps it doesn’t deserve that “application-fluent” title.

Staying Relevant in an App-Driven World

In a modern, app-driven world, realizing how many applications and protocols must be supported to enable a flexible and functional version of this model can make your brain hurt.

Some vendors take this stuff more seriously than others, constantly expanding and enhancing their protocol support in variety and depth. Whether it’s HTTP, SQL, SNMP, FIX, or just highly optimized TCP that you need, my advice is to keep looking until you find a vendor that can get you as close to app fluency as possible.

Of course, no vendor can possibly support every protocol for every scenario, so it’s best to add flexibility wherever possible, empowering the people building and deploying the solutions. That needs to be done in a way that they understand, appreciate, and can use to great effect.

Ultimately, that means programming.

That’s still a dirty word for some networking people, although I don’t understand why. Some seem to think that things like deeply integrated APIs and readily available on-box scripting aren’t necessary to achieve application fluency. I invite those folks to pry up the rock under which they’ve been living and come join the rest of us who aren’t stuck in denial. To play a role in understanding, delivering, and modifying applications, a device must be able to act like one. It must become part of the application world rather than just a platform for apps to sit on. And it must allow applications to run at full potential and deliver the ultimate user experience.

Still not convinced this whole app fluency thing is important or useful? Does anything on this list sound handy?

  • Increased application performance
  • Increased application resiliency
  • Better, more controlled user experience
  • Dynamic, powerful exception and error handling
  • Dynamic scaling (up/down) based on application needs
  • Avoidance of app dev cycles that lead to painful delays (security, urgent functional changes, etc.)

This is just a smattering of the potential benefits of application fluency at the network level. So get with the times, learn a scripting language or two, and go shake hands with that dev team you’ve been loving to hate all these years. It’s time to bury the hatchet and show them just how powerful an ally the network can be. Face it, without solid programmability built into the network layer, you’re living in the past.

This isn’t 1997. There’s no reason your network needs to act like it is.

Colin Walker, F5 NetworksColin Walker is a self-described “programmability zealot” and Product Management Engineer at F5 Networks, where he guides product development and evangelizes the technology. 

Header photo courtesy of Shutterstock.

Latest Articles

Follow Us On Social Media

Explore More