Purpose

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

Intended Readers

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 mim OE Runtime, images, containers and microservices in the mimik ecosystem.

What You Will Learn from this Document

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

What You Need to Know Before You Start

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

mim OE Deployment Strategies

Microservices written to run under the mim OE 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.

Deploying a Standalone edge Microservice

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 mim OE Image of the microservice under development. That mim OE Image will be used as the template for creating a mim OE Container. (See Figure 1, below)

Figure 1: The deployment pattern for a standalone edge microservice

The details about mim OE Images and mim OE Containers are discussed in the section, Understanding mim OE Images and mim OE 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 a mim OE Container running the particular microservice.

Deploying an edge Microservice as a Constituent Component

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 a mim OE 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 mim OE. The developer will then write additional code that injects the microservice into the running instance of mim OE. The developer's application code creates the mim OE Container representing the microservice from the .tar file that is the particular mim OE Image.

Deploying an edge Microservice as an iOS Component

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 mim OE 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 mim OE Runtime by integrating the mimik Client Engine Library or have an instance of mim OE Runtime running on a host platform of their choosing (ie. macOS, Lunix, Windows, etc.)

The .tar file representing a mim OE 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 mim OE Runtime within the iOS runtime environment. The developer writes additional application code that uses the .tar file as a mim OE Image against which a mim OE 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.

Deploying an edge Microservice as an Android Component

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 mim OE 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 mim OE Runtime. Also, the developer will write code that injects the edge Microservice created from the downloaded mim OE Image tar file that represents a mim OE 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.

Deploying an edge Microservice as a macOS Component

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 mim OE 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 mim OE 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 mim OE instance as a subprocess.

When running a custom edge microservice as a Mac desktop application, once the mim OE 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 mim OE 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.

Deploying an edge Microservice in a Linux Desktop Application

Writing an edge microservice for a Linux Desktop application involves getting the mim OE 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 mim OE 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 mim OE 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 mim OE 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 mim OE 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.

Deploying an edge microservice as a Windows EXE Component

In terms of using an edge microservice in a Windows application, the developer must first make it so that an instance of the mim OE Runtime is available on the local computer. The developer downloads the Windows version of the mim OE Runtime from GitHub, here. Then, the developer has a choice. The mim OE Runtime can be invoked directly from the command line on the local computer. Or, the developer can write custom code that invokes the mim OE 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 mim OE 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 mim OE 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 mim OE Runtime. (See Figure 5, below)

Figure 5: The deployment pattern for an edge microservice used in a Windows executable

The application is typically deployed by the developer as a standalone binary that's downloaded from the developer's web site.