For several years now, my cohort Cindy Borovick and I have conducted, compiled, and analyzed thousands of responses from IT professionals across the globe in response to our State of Application Delivery surveys. The primary focus of this survey is, as is totes appropriate for F5, focused on understanding the app services landscape. As we release the findings, we’re often asked the same question by those not as intimately familiar with the technology, “What are app services?”
It’s a good question, and one that deserves an answer. And a picture. Because what’s a tech blog without a picture? Boring. That’s what it is, boring.
The simplest answer to the question is “an app services is any network-hosted service that inspects, modifies, rejects, forwards, or modifies application data.” Or as I might explain to someone outside IT, an “app service is a waypoint set in your navigation system between where you are and your destination.” Because that’s really what they are; waypoints in the data path.
The data path spans local networks, the Internet, and corporate networks. It’s the route every single packet takes to get from point A (client) to point B (app). While traversing that data path, packets must travel through a number of devices and services, each providing network and application functions that span simple routing to complex cryptographic processing. In our surveys, we track twenty-six (26) different services providing security, performance, identity and access, mobility, and availability support for applications and users alike. These services are all deployed in the data path, meaning that application requests and responses must pass through them in order to reach their destination, whether that be the client (outbound) or the app (inbound).
Each application has a different set of requirements and needs, and thus each application is likely to have its own unique data path and set of app services addressing those requirements and needs. Some of those may be business driven and others by regulations. Irrespective of their origins, they must be met. Which is why app services exist.
This is also why we include networky services like “network firewall” in the app services fold. Network firewalls are the least application aware, usually being only interested in ports and IP addresses, but they are application aware. And they are one of the services through which the data path must pass. It is the most commonly deployed app service of those we track, with 83% of respondents indicating at least one in deployment right now.
Beyond the network firewall, the data path encounters a wide variety of app services. Interestingly enough, the inbound data path may not be the same as the outbound data path. That’s the reason I separated them in the obligatory diagram. In fact, in today's highly programmable world, it is increasingly the case that the data path fluctuates not just from app to app, but on request to request. Service provider networks are notoriously demanding with respect to speed, and just as we can’t ignore the limitations of the speed of light on data transfer rates, we cannot ignore that at least nominal latency (delay) is added every time a service inspects a request or response. Thus, service network operators have become experts at dynamic service chaining, which adjusts the data path in real time based on the application data it is currently transporting.
Most enterprise networks are less flexible by design, but are still likely to exhibit differences between inbound and outbound data path with respect to app services. A good example is security. A quick look at the data path protection strategies of respondents in our latest survey shows differences in how often inbound and outbound data paths are protected by app services. It’s slightly more common to find a security app service like a web application firewall protecting the inbound request than it is to find one protecting the outbound response. Thus inbound requests may take a different route than their corresponding outbound responses.
App services, then, run the gamut of “functions” one might find in the network. What they share is a common definition: the data path passes through the service (inbound or outbound or both), allowing inspection, rejection, forwarding, or modification of application data. The application qualifier is vital, as otherwise we’d need to include things like switches and routers, which rarely act on application data and instead are focused on passing packets based on network data as quickly and efficiently as possible.
App services include (but are not limited to): DNS, load balancing, web app firewalls, network firewalls, SSL VPN, caching, TCP optimization, and SSL/TLS offload services. Most organizations on average employ at least 14 of the 26 services we track, with nearly three-quarters (74%) deploying at least ten app services as of 2017. That makes my included diagram a bit simplistic, as it doesn’t do justice to the robust deployments of app services in real environments. The curvy data path line is, though, because cables run up and over and through all sorts of physical barriers and racks and patch panels. Really. They aren’t the straight lines we like to show in diagrams.
We (F5) ask about app services in our annual survey cause that’s what we do – provide app services to organizations so they can make their apps go, whether in the cloud or in the data center (or somewhere that’s kind of both). Over the years these services have become essential components of app deployments, rather than “nice to have add ons”. Scale, speed, and security are no longer optional for apps, they’re base requirements that more often than not necessitate the use of app services.
Whether you’re aware of them or not (and in most cases, it’s hoped you’re not) just about every request made to an app – whether via an API or a URL in a browser – traverses at least one app service, likely more. Whether it’s scale or security or performance, applications today are made safer and faster because they’re assisted by app services.