Device detection in your environment: deployment options

Device detection is an essential asset for every business that wants a solid understanding of all devices its customers use to access their web apps and other web content. It can either be used for web optimization projects or embedded in a product, adding device awareness to enhance targeting and reporting capabilities. DeviceAtlas has several deployment options to match your infrastructure requirements. Here’s what’s possible.

Locally-deployed DeviceAtlas for web serving use cases

A locally-installed version of DeviceAtlas gives you access to a number of deployment options specifically tailored to your needs and infrastructure. Depending on where DeviceAtlas is actually installed, we can list three different options which you may consider.

1. Per-server installation—individual APIs available for Java, PHP, C++, C, .NET, Python, Ruby, Node.js, and Go (golang)
2. On network edge—web server modules for Apache, NGINX and IIS

   Note: modules for a load balancer (HAProxy) and a caching layer (Varnish Cache) are also available

3. For wide-scale deployments—a combination of available deployment options for the most complex infrastructures

Read on as we explain each of these deployment options in more detail.

1. DeviceAtlas per-server installation

In this deployment option, an instance of the DeviceAtlas API and the dataset are installed on each application server. Applications use the DeviceAtlas API directly and consume the local device data before responding to requests.

Integration overview

This is a straightforward way to integrate device detection since no real infrastructure effort is required—each application can load and consume device data as required and use the appropriate language version of the API.

Some customers report that they successfully added device intelligence to their services in less than an hour, but of course, the level of effort depends on how extensively device data will be used.

When it's a good fit

This option is a good fit if what you're looking for is the ease of integration and the low latency as there are no calls across the network. The highest speed of detection is achieved if your application servers are using C or C++. However, even if you’re using script-based languages, such as PHP, the performance of C/C++ can still be achieved by using a web server module (described in the next section).

Bear in mind that all application servers are required to have a copy of the DeviceAtlas API installed and the data file present locally, or shared on a network file system. A mechanism for distributing the data file (updated daily) across servers on a regular basis is required.

2. DeviceAtlas on Network Edge (web server, load balancer, caching layer modules)

As mentioned above there are Apache, NGINX and IIS modules which leverage the C API available. These allow a single instance of DeviceAtlas to make device data available to any downstream applications that wish to consume it, regardless of the programming language that they are written in.

Integration overview

The DeviceAtlas device information is inserted into environment variables or HTTP headers that are easy and efficient to query in most programming languages. Thus, a single highly efficient instance of DeviceAtlas can serve a range of downstream applications with no additional library requirements or local data on each application server. In effect, the device data becomes automatically accessible to any downstream application.

When it's a good fit

The main advantage of this deployment option is the efficiency and speed gains that are possible. In addition, downstream log processing gets access to the full device information, thus enriching analytics.

Since it leverages a high-performance API, a single instance of DeviceAtlas can serve significant volumes of traffic with very little additional overhead. This deployment option is also efficient since only one instance of the DeviceAtlas dataset is required, and thus there is no memory impact on downstream servers. In addition, the server footprint is low from a CPU and memory perspective.

It may take slightly longer to set up, depending on the configuration of the existing front-facing web servers, but expert support is provided by DeviceAtlas R&D team.

Note: In the case of NGINX, the DeviceAtlas module can be used in conjunction with other modules to create powerful solutions. For example, NGINX includes an image adaptation module. This works well with the DeviceAtlas module to automatically tailor image sizes for the visitor, based on screen size information. This can be easily implemented by sysops staff, with no intervention needed at the website level, and it delivers material page weight reductions and infrastructure cost savings. Learn more >>

3. Wide-scale deployments of DeviceAtlas

Some customers with very high volume infrastructures choose to deploy DeviceAtlas as a service available to all applications.

Integration overview

This option makes the most sense when multiple different applications are using DeviceAtlas in different ways, and where a centralized architecture can be made fast enough to work well. In this type of deployment, DeviceAtlas is typically configured to be available for queries via REST API, thus making it language-neutral and relatively efficient to query across the network.

In this deployment model, it makes sense to use the fastest APIs available. In the case of DeviceAtlas this would normally mean C, C++ or Java.

When it's a good fit

The main advantages of this option are efficiency, ease of device data updates and programming language neutrality.

This deployment option requires a more significant level of engineering effort since the central server solution must be designed and built, both the server and client. It may be possible to layer this solution into an existing infrastructure component, however.

Also, this DeviceAtlas deployment option can be affected by the remote nature of the server: you may expect some level of latency with each request. Obviously, the ease of integration, in this case, depends entirely on the choices made by the implementer.