Application services are everywhere

#SDAS #SDN Application services are closer to apps than they are the network and like apps, they're everywhere.

SDN has begun to recognize that it can't just focus on lower order (L2-4) network services. The bulk of network services actually resides much higher in the stack, at layers 4-7, and are widely (very widely, in fact) deployed. While not every app uses every application service available, just about every application uses some application services to address challenges with performance or security or access or simple availability.

That means organizations have a lot of these "application services" they need to manage and, more importantly to those concerned with improving the velocity and success of application deployments, provision and configure.

But what are these "L4-7 services" so often mentioned in various articles waxing predictive about the future of SDN and other operationally focused technologies?

Application services are, to be honest, more application than they are network services. Each one encapsulates some kind of function, some particular focus, that is executed on either incoming or outgoing application data. Sometimes both.

It is that logic that must be executed that raises them closer to the level of application than to down to the network. If you consider for a moment something like application security or application access, you can start to see what this means.

When a switch receives an incoming packet it has to do a couple of things that boil down to examining the source and destination IP addresses and ports, applying any access or quality of service controls, and sending it on its way. It's fast (really fast) and the logic is so simple it doesn't need a lot of compute to do.

When an application security service receives an incoming request (not a packet, but all of the packets that make up the request) it has to start executing some fairly complex logic on it. It needs to parse it (just like the browser or the app itself would do) and examine it for anomalies. It has to decode it if it's been encoded. Decrypt it if it's been encrypted. It has to validate the data types of various input fields against those specified as valid. It has to process and evaluate the entire message - from HTTP to URI to unstructured data. Only then can it deem the request acceptable and send it on its way. That takes a lot more compute than simply matching IP addresses and ports against a lookup table. It takes logic, much the same kind of logic that would be found in an application that might do the same thing.

And it can't be burned into silicon because it's not the same every time. It's flexible, configurable, and eminently changeable. It's software, not hardware.

Application services encompass a wide variety of functionality, from simple load balancing to highly complex application security to highly demanding access and identity management. They interact with and intermediate for applications to do the things applications can't do or can't do at scale. They speak both network and application protocols because they have to do the former to be able to be in the data path, and the latter because the capabilities they provide focus on applications and their data.

Almost all application services start out as, well, applications. In the early days application services were often deployed as applications on highly tuned server platforms (like Apache). But the problem is that they didn't scale well on those platforms, any better than applications did. But load balancing proxies did. The marriage of the two produced what would later be called "application delivery controllers" which, if you break it down to its component parts, are a bunch of very focused applications deployed on a really fast proxy platform.

That's over simplifying it, to be sure, but at a very high level that's really what we're talking about. Application services are highly specialized application logic deployed on high performance, high capacity proxy platforms in the critical data path, in the network.

And they're everywhere.