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.
DISSECTING 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
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.
About the Author
Related Blog Posts
The everywhere attack surface: EDR in the network is no longer optional
All endpoints can become an attacker’s entry point. That’s why your network needs true endpoint detection and response (EDR), delivered by F5 and CrowdStrike.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.
F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
Volterra and the Power of the Distributed Cloud (Video)
How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.