Key Concepts
Understanding the Strategies for Deploying an edge Microservice

Understanding the Strategies for Deploying an edge Microservice

The purpose of the document is to provide a conceptual description of how to deploy edge microservices in the edgeEngine ecosystem.

The intended readers of this document are software developers, system engineers, application architects, deployment and security personnel as well as other technical professionals who want to understand the details of the strategies and techniques that are relevant to deploying the edgeEngine Runtime, images, containers and microservices in the edgeEngine ecosystem.

After reading this document, you will have a conceptual understanding of:

The general strategy for deploying an edge microservice
The strategy for deploying an edge microservice to an iPhone or Android device
The strategy for deploying an edge microservice as a standalone Linux application
The strategy for deploying an edge microservice as a standalone Windows application

In order to get the full benefit from reading this document, you need to have an understanding the the edgeEngine Runtime and how it supports microservices. Also, it's useful to understand the key concepts relevant to edgeEngine Images and edgeEngine Containers.

Microservices written to run under the edgeEngine Runtime are typically intended for specific target devices and operating systems. The targets are:

Apple devices running iOS
Android devices running Android
Mac computers running macOS
Desktop computers running the Linux operating system
Raspberry Pi computers running the Raspian Operating System
Windows compatible devices running the Windows Operation system as of version Windows 10.

There are two general patterns for the deployment of an edge microservice. The first pattern is one in which a developer creates an edge microservice and then deploys that microservice as a standalone artifact to a target device.

The second pattern is that the developer will create the microservice as a component that will be hosted in another application.

In the case of creating microservice as a standalone artifact, the source code for the microservice, which is typically written in Node.JS, will be stored in a Git repository service such as GitHub, GitLab or BitBucket. Then the developer will clone that source code down from the git repository and create the .tar file that represents the edgeEngine Image of the microservice under development. That edgeEngine Image will be used as the template for creating an edgeEngine Container. (See Figure 1, below)


Figure 1: The deployment pattern for a standalone edge microservice

The details about edgeEngine Images and edgeEngine Containers are discussed in the section, Understanding edgeEngine Images and edgeEngine Containers.

The developer creates the tar using the npm package and npm build command sets that are part Node.JS application framework for building edge microservices. (You can view an example of an edge starter microservice here.) Once the .tar file is available and downloaded to a hosting device such as a Raspberry Pi or a server-side Linux computer, the developer uses the mimik edge CLI tool (mimik-edge-cli) to deploy the .tar file in the host device as an edgeEngine Container running the particular microservice.

edge microservices can be deployed as a constituent component that's part of a host application. The host application can be written in a variety of programming languages and runtime frameworks.

Essentially, the pattern is that a .tar file representing an edgeEngine Image is embedded into the source code as a component that's used by the host application. The way the component is embedded into the host application is that a developer writes application code that uses the mimik Client Library to create a running instance of edgeEngine. The developer will then write additional code that injects the microservice into the running instance of edgeEngine. The developer's application code creates the edgeEngine Container representing the microservice from the .tar file that is the particular edgeEngine Image.

Embedding an edge microservice with an iOS application uses the constituent component pattern described above.

However, when it comes to writing an iOS app, the developer creates the application code for deploying and accessing the edge microservice in Swift. As described above, the developer will use the mimik Client Library in the application code to manage the running instance of edgeEngine Runtime under which the particular microservice will run. (The mimik client library for iOS is installed from the CocoaPod repository.)

The developer can either embed the edgeEngine Runtime by integrating the mimik Client Engine Library or have an instance of edgeEngine Runtime running on a host platform of their choosing (ie. macOS, Lunix, Windows, etc.)

The .tar file representing an edgeEngine Image for an edge microservice can be stored in a file storage service such as AWS S3 or a file server on an internal network. Then, the developer downloads that .tar file onto the target development computer. Once the .tar file is downloaded into the application source code, the developer writes code that leverages the mimik client library to create a running instance of the edgeEngine Runtime within the iOS runtime environment. The developer writes additional application code that uses the .tar file as an edgeEngine Image against which an edgeEngine Container representing the given microservice is deployed.


Figure 2: The deployment pattern for an edge microservice used as an iOS component

After the developer's iOS application is bundled and made ready for deployment to the public, the application will be submitted to the Apple App Store. Then, upon approval, those who are interested in using the application on their iOS devices can download it directly from the Apple App Store.

In the case of an Android or Java application, the edge Mobile SDK is encapsulated into a Maven component that the developer uses to create a running instance of the edgeEngine Runtime, similar to the technique described above for creating iPhone/macOS applications.

There are two ways to use the Maven version of the edge Mobile SDK. One way, using Maven, is to include the definition of the edge Mobile SDK component as a dependency in the application's POM.xml file, like so:

1: <dependency>
2:   <groupId>com.mimik.edgesdk-android-client</groupId>
3:   <artifactId>edgemobileclient-core</artifactId>
4:   <version>0.0.20</version>
5: </dependency>

The other way uses Gradle. When using Gradle you include a reference to mimik's Maven repository at the project level instance of the build.gradle JSON file as shown in the example below:

1: buildscript { 
2:     repositories {
3:         google()
4:         jcenter()
5:     }
6:     dependencies {
7:         classpath 'com.android.tools.build:gradle:3.2.1'
8:         
9:         // NOTE: Do not place your application dependencies here; they belong
10:         // in the individual module build.gradle files
11:     }
12: }
13: 
14: allprojects {
15:     repositories {
16:         google()
17:         jcenter()
18:         maven {
19:             url "https://s3-us-west-2.amazonaws.com/mimik-android-repo"
20:         }
21:     }
22: }
23: 
24: task clean(type: Delete) {
25:     delete rootProject.buildDir
26: }

Then, within the application level instance of the build.gradle JSON file, you define the dependency to the edge Mobile SDK Maven component in the dependencies node as shown below:

1: apply plugin: 'com.android.application'
2: 
3: android {
4:     flavorDimensions "full"
5:     compileSdkVersion 27
6:     defaultConfig {
7:         applicationId "com.mimik.example"
8:         minSdkVersion 21
9:         targetSdkVersion 27
10:         versionCode 1
11:         versionName "1.0"
12:         multiDexEnabled true
13:         testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
14:         manifestPlaceholders = ["appAuthRedirectScheme": "com.mimik.example.appauth"]
15:     }
16: 
17:     buildTypes {
18:         release {
19:             minifyEnabled false
20:             proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
21:         }
22:     }
23: 
24:     productFlavors {
25:         prod {
26:             dimension "full"
27:             buildConfigField "String", "MID_URL", '"https://mid.mimik360.com"'
28:             buildConfigField "String", "APPAUTH_CLIENT_ID", '"ab933bf9-2131-4c08-8ab3-1f7086387ee2"'
29:         }
30:     }
31: }
32: 
33: dependencies {
34:     implementation fileTree(dir: 'libs', include: ['*.jar'])
35: 
36:     implementation 'com.android.support:appcompat-v7:27.1.1'
37:     implementation 'com.android.support.constraint:constraint-layout:1.1.3'
38:     implementation 'com.google.android:flexbox:0.3.2'
39:     implementation 'com.google.android.gms:play-services-location:16.0.0'
40: 
41:     testImplementation 'junit:junit:4.12'
42:     androidTestImplementation 'com.android.support.test:runner:1.0.2'
43:     androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
44: 
45:     implementation 'com.squareup.retrofit2:retrofit:2.1.0'
46:     implementation 'com.squareup.okhttp3:okhttp:3.10.0'
47:     implementation 'com.squareup.okhttp3:logging-interceptor:3.6.0'
48:     implementation 'com.squareup.retrofit2:converter-gson:2.1.0'
49: 
50:     implementation 'com.mimik.edgesdk-android-client:edgemobileclient-core:0.0.20'
51: }

Once the edge Mobile SDK is installed using either the Maven or the Gradle build techniques, the developer writes custom Java code that creates a running instance of the edgeEngine Runtime. Also, the developer will write code that injects the edge Microservice created from the downloaded edgeEngine Image tar file that represents an edgeEngine Image. (Downloading the tar file was discussed in the previous section.)


Figure 3: The deployment pattern for an edge microservice used as an Android component

After the developer's Android application is bundled and made ready for deployment to the public, the application will be submitted to Google Play as an .apk binary. Then, upon approval, those who are interested in using the application can download the .apk directly onto their Android device from Google Play.

When it comes to writing a Mac app, the developer creates the application code in Swift.

Writing an edge microservice for a Mac Desktop application involves getting the edgeEngine Runtime downloaded on the local computer and then invoking the particular microservice represented by a .tar file.

First, the developer downloads the latest version of the edgeEngine Runtime in the mimik GitHub repository found here. Then, the developer will write custom code that deploys it as a service. That service creates the edgeEngine instance as a subprocess.

When running a custom edge microservice as a Mac desktop application, once the edgeEngine Runtime is invoked, the developer has another choice to make. The developer can write code that downloads the .tar file that represents the custom microservice from a file storage service such as AWS S3, Azure Files, a file server private to an internal network or from a git repository such as GitHub. Or the developer can build the .tar file from the source. Then, the developer writes additional code that will use the mimik Container API (mcm) to inject the microservice into the edgeEngine Runtime.

A Mac desktop application that implements an edge microservice is typically released by the developer as a standalone bundle that's deployed using a system typical of the given Mac distribution.

Writing an edge microservice for a Linux Desktop application involves getting the edgeEngine Runtime downloaded on the local computer and then invoking the particular microservice represented by a .tar file.

First, the developer downloads the latest version of the edgeEngine Runtime in the mimik GitHub repository found here. Then, the developer will write custom code that deploys the application as a binary file. That binary file creates the edgeEngine instance as a subprocess. The binary can be written in a variety of languages such as Go, Rust, C++, or Java using the JVM.

When running a custom edge microservice as a Linux desktop application, once the edgeEngine Runtime is invoked, the developer has another choice to make. The developer can write code that downloads the .tar file that represents the custom microservice from a file storage service such as AWS S3, Azure Files, a file server private to an internal network or from a git repository such as GitHub. Or the developer can build the .tar file from the source. Then, the developer writes additional code that will use the mimik Container API (mcm) to inject the microservice into the edgeEngine Runtime.


Figure 4: The deployment pattern for an edge microservice deployed as a Linux Desktop Application

A Linux desktop application that implements an edge microservice is typically released by the developer as a standalone binary that's deployed using the package management system typical of the given Linux distribution. For example, under Ubuntu, the deployment unit is a Debian package (.deb) deployed using the apt or snap package manager system.

In terms of using an edge microservice in a Windows application, the developer must first make it so that an instance of the edgeEngine Runtime is available on the local computer. The developer downloads the Windows version of the edgeEngine Runtime from GitHub, here. Then, the developer has a choice. The edgeEngine Runtime can be invoked directly from the command line on the local computer. Or, the developer can write custom code that invokes the edgeEngine Runtime as a subprocess. This code can be written to run as a standalone binary or as a .NET application.

When running a custom edge microservice on Windows, once the edgeEngine Runtime is invoked, the developer has another choice to make. The developer can write code that downloads the tar file that represents the custom microservice from a file storage service such as AWS S3, Azure Files, a file server private to an internal network or from a git repository such as GitHub. Then, the developer writes additional code that will use the mimik Container API (mcm) to inject the microservice into the edgeEngine Runtime.

The other way is to include the .tar file in the binary exe file as an embedded resource. The binary exe will have code that also uses the mimik Container API to inject the microservice into the edgeEngine Runtime. (See Figure 5, below)