mimik Developer Documentation

Understanding the Strategies for Deploying an edge Microservice

Purpose

The purpose of the document is to provide a conceptual description of how to deploy edge microservices in the edgeEngine 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 edgeEngine Runtime, images, containers and microservices in the edgeEngine 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 edgeEngine Runtime and how it supports microservices. Also, it's useful to understand the key concepts relevant to edgeEngine Images and edgeEngine Containers.

edgeEngine Deployment Strategies

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

  • iPhones running iOS
  • Android cell phones running Android
  • Macintosh 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 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)

standalone deployment
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.

he 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.

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 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 edgeEngine Mobile SDK 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.

Deploying an edge Microservice as an iPhone or macOS Component

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

However, when it comes to writing an iOS app, the developer creates the application code for hosting the edge microservice in either Swift or Objective C. As described above, the developer will use the edge Mobile SDK in the application code to create the running instance of edgeEngine under which the particular microservice will run. (The edge Mobile SDK for iOS is stored in a CocoaPod repository.)

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 edgeEngine Mobile SDK to create a running instance of the edgeEngine Runtime within the iPhone/macOS 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.

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

After the developer's iOS/macOS application is bundled and made ready for deployment to the public, the application will be submitted to the Apple App Store as an ipa binary. Then, upon approval, those who are interested in using the application on their iOS device or Macintosh computer can download it directly from the Apple App Store.

Deploying an edge Microservice 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 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.)

android deployment
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 in a Linux Desktop Application

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 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.

linux desktop deployment
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 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)

windows deployment
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.

© 2022 mimik Technology Inc. All Rights Reserved