App Servers as Insertion Points

In a previous post, we explored the notion of adding app services to shifting app architectures using a concept we call "insertion points." For those who haven't followed along, an insertion point is an architecturally distinct location in the code to customer data path at which it makes sense to add functionality that is often outside the purview of development or operationally more efficient. 

A robust set of capabilities add or enhance the applications that represent business activities today.

Insertion points include the client, infrastructure, and the app itself. Each point has its pros and cons when it comes to balancing operational and cost efficiencies. For example, it is likely not operationally or cost-efficient to insert a network-centric DDoS app service into the client or the app. This is because neither insertion point has access to the hardware-accelerated capabilities available with an infrastructure option nor do they have the visibility necessary to make an accurate determination. 

So, what we're looking for are app services that are both operationally and cost efficient at the point of insertion; in this case, we're focused on the app server (platform) itself.

The App Platform as an Insertion Point

At first, this insertion point may seem like an odd choice. App servers host and deliver apps, not app services. But if you consider the role NGINX and other app servers play today, you'll find them often playing the part of both infrastructure and server at the same time. For example, some app servers can and do act as an SSL termination point. SSL termination is an app service, often coupled with SSL offload (hardware acceleration). Web app firewall services, too, are often coupled to app servers via plug-ins.

The use of the app server as an insertion point is neither new nor foreign. In our 2020 State of Application Services research we asked about this option for deploying app services. We found that there is interest in this insertion point. About 6% of respondents would like to use a "plug-in" for app services. Another 9% would prefer "as a service," which requires a companion piece of code (injected or included) to invoke. A small number, 4%, would like to use a library to include app services. This last option is something we see frequently used to insert functionality into serverless (function as a service) applications.

In many cases, deploying an app service on an app server makes good operational sense. Because these services are often configured to serve a single app, they can be packaged and deployed by the same team. Expertise with the app server ensures greater confidence and ease of integration into ecosystems and deployment pipelines.

In some cases, it will make sense to deploy the app and app service together, on the same instance of a single app server. For example, app protection via an app-specific policy can be plugged-in and executed as a step in the processing of requests and responses. That the functionality is invoked from within the server makes sense and, if inspection is executed locally, can improve performance by eliminating extra hops and processing by services hosted outside the environment. That can make it more efficient both operational and financially, especially if you’re paying by the hour or invocation for the service.  

Whether the app server is used to host a stand-alone app service or as a host to both app and app service, the app server is certainly a good insertion point for the right app services.