Multi-Container Applications

February 11th, 2020

Headshot for Bruce Armstrong

Bruce Armstrong

Principal Engineer

In the MobiledgeX environment, application backend software in the form of a container (think Docker and Kubernetes) is deployed. In a simple design, all services provided by your backend may all be included in a single container, that can be installed in various locations.

Why Multi-Containerize?

Using MobiledgeX's Edge Computing infrastructure is a great way to improve performance in your latency-sensitive app. But what if your app accesses various services, and some of those are not as latency dependent? What if your app's backend runs on multiple servers in multiple locations, and all instances need to share data? In both of these cases, it may make more sense to run only part of your backend on the Edge, and another part of it in the public cloud.

This article discusses a use case where multiple instances of our containerized application need to share the same data. In this case, we have a centralized server where shared data is collected, processed, and stored, and each Edge instance will download that data every time it is updated.

Use Case: Face Recognition

The MobiledgeX SDK Demo app for Android includes a Face Recognition activity used to demonstrate the latency advantages of mobile edge computing. The red "Cloud" numbers in the screenshot represent the latency values when the Android client sends images from the camera to be processed by a Face Recognition server hosted in the public cloud. The green "Edge" numbers are obtained by doing the same with a Face Recognition server hosted on a MobiledgeX cloudlet. The edge cloudlet may be selected from a map to compare the latency for various geographical locations. In this instance, we want the face training data to be available no matter which edge cloudlet we select.

Original Design

In the initial design, each server stood alone on its Edge cloudlet. There was no communication between servers. If a user's face training took place on Cloudlet "A," and they then moved from Cloudlet "A" to Cloudlet "B," their face would no longer be recognized.

Multi-Containerized Design

In the new design, the master copy of the face training database exists in one central location: The Face Training Server, which is hosted in the public cloud. Instances of the Face Recognition Server are still running on multiple geographically separated edge cloudlets, and the face training database is downloaded by each one at startup time, and any time it has been updated.

In our Android face recognition app, we now must communicate with three different servers:

  1. The Edge Cloudlet Face Recognition Server.

  2. The public “Cloud” Face Recognition Server.

  3. The Face Training Server which lives in the public cloud.

The Face Recognition Servers also communicate with the Face Training Server, pulling down the new training database both at startup time and any time the database has been updated.

Because with our REST API, there is no concept of a "session," when the client first connects to a Face Recognition Server, it sends an "update" command, telling the Face Recognition Server to check the face training database timestamp on the Face Training Server. If the timestamp is newer than the local copy of the database, the updated training database is downloaded.

When the client is in training mode, it sends images to the Face Training Server. Images are only accepted if there is a face detected. When enough images are submitted, the "train" procedure is performed. Once this is complete, the client resumes sending images to the Face Recognition Servers.


Face Training Server

The following microservices are provided by the Face Training Server and are accessed via a REST API:




Add image


Adds a face image to the database and associates it with the given subject name.

Perform training


Performs the training process on all uploaded images and updates the face training database.

Download face training database


Returns the complete face training database in the form of a Gzipped YAML file.

Get face training database timestamp


Returns the timestamp of the face training database.

Recognize a face in an image


Performs face recognition on the given image and returns the coordinates and subject name for the recognized face. (Not used in production, but valuable for testing.

Remove trained images


Removes face images for the given subject name.

Face Recognition Server




Recognize a face in an image


Performs face recognition on the given image and returns the coordinates and subject name for the recognized face.

Update face training database


Checks with the Face Training Server, and if the timestamp of the face training database is newer than the local copy, downloads the updated version.