Appspace utilizes open technologies wherever possible to ensure maximum flexibility for our customers. To this end, Appspace has not created a bespoke caching solution and does not sell or support caching nodes. Each customer’s goals, network, and environments are unique; therefore there is no single solution that will work in all situations.
The following recommendations should be viewed as a starting point and are intended to be used as a guide. Every customer’s situation will be different and these recommendations should be modified by the customer’s networking and web server teams to meet their specific needs.
Many customers would like a solution to locally cache content that is served by the Appspace platform. The most common reasons for this include more efficient ingress bandwidth utilization, increased speed of content delivery, and improved security.
A single element in a caching solution is known as a caching node. A caching solution may consist of one or multiple caching nodes. If there are multiple nodes, it is possible for them to work together or individually (without knowledge of each other). If the nodes work together, they can form a network of caches. Caching can occur at multiple levels, including at a single network-wide cache tree, or on a hierarchy of site-level caches within a geographically distributed network. Content caching is equally applicable to cloud-based and on-prem deployments.
This guide will not provide a detailed discussion of caches or reverse proxies. This guide will focus on how these technologies can be applied in concert with the Appspace platform. There are many freely available guides that discuss how these technologies work and can provide architectural guidance.
The typical goals for implementing this solution include:
The Appspace recommended solution utilizes these readily available, well proven, and highly scalable off-the-shelf software components:
We recommend using a number of caching nodes which may be deployed across a network. These nodes may be dedicated to servicing specific local networks (branch office, store, etc), combined into load balanced groups, and/or organized hierarchically. The simplest scenario consists of a single caching node on the network edge.
Here is a simple diagram showing a single caching node and Appspace network traffic. More nodes can be added for each geographical or logical network location.
Appspace has three general categories of network communications:
A reverse caching server can expose one of the following two types of hostnames:
The Appspace platform utilizes the second approach, exposing a different hostname for the caching server and a different URL for the cached content. A reverse caching proxy software has many settings to control storage usage, bandwidth management, and such, which can be applied according to customer’s preference.
To implement a caching strategy, the following steps are required (explained in detail in sections below):
The solution that Appspace recommends for simplicity and reliability is Apache on Linux.
The reverse proxy should meet the following requirements:
Apache is a powerful and popular open source web server software that can be deployed on Linux or Windows. The solution discussed here assumes Linux based deployments, however, it should work equally well on Windows, if that is preferred.
Reverse caching servers integrate into existing networks and fully utilize SSL capabilities. Reverse caching proxies terminate SSL connections and interpret request data. Because they operate on their own hostname, they need to have a separate certificate for this hostname.
[Client] ---> [https://cache.customer.com/] ---> [Appspace]
The Appspace App retrieves content using a URL that will be set when the device is registered with the Appspace platform. This address can be overridden to direct the app to an external content source, which could be a content caching node. All other Appspace traffic will continue to be directed to the default Appspace address.
To override the content source location, these two addresses must be modified via device properties:
When this option is used, the Appspace client will verify the CDN by pinging the ping URL. If successful, the client will begin downloading all content from the new CDN. Should this verification fail, the Appspace client will fall back to downloading content from the original Appspace CDN. The Appspace App will continue to retrieve timestamps, content scripts, device tasks, and alerts from Appspace directly.
The HTML5-based Appspace App supports this functionality on all certified devices.
This function is also supported on legacy Cisco DMP-4310, DMP-4400, and EDGE-300/340 devices.
However, the legacy DirectX-based Appspace App does not support fetching content via an external CDN or caching node.
Please reach out to your Appspace representative to engage in a deeper discussion around configuration recommendations and best practices.