developer portal

Documentation

edgeSDK Concept

mimik edgeSDK brings the flexibility and scalability of central cloud computing to the edge of the network. It is an optimization strategy for performing data processing at the edge of the network (edge computing), we believe bringing cloud technology to the edge computing further help realizing the true potentials of edge computing. And mimik calls this computing concept as edge-cloud computing.

mimik edgeSDK provides a hybrid edge-cloud computing platform that features cloud-platform-like solutions, such as clustering, network traffic routing, serverless microservice, container technology, and OpenID authorization to the edge. Furthermore, we also provide mimik's backend services to aid the edgeSDK edge-cloud computing platform in areas such as network bootstrapping and private network tunneling.

Nodes

The concept of turning all computing devices into edge nodes is the fundamental building block of mimik's edge-cloud computing technology. Each device that runs edgeSDK is defined as an edge node that takes a role in the network depending on the host platform constraints and its ability to provide computing resources to the edgeSDK edge-cloud computing ecosystem.

Clustering

Clustering is the division of the network into different virtual groups, based on rules for allocating edge nodes to different networks. edgeSDK provides three ways of clustering:

Link Local

This clustering method is based on using the connected local network to create a virtual group. One of the edge nodes in the cluster is the knowledge holder called the Supernode.

The Supernode stores identification infromation about other edge nodes in the linkLocal cluster. The supernode is elected via an election algorithm, and is responsible for routing control-based networking data to other nodes in a linkLocal cluster.

Account

This clustering method uses the end user's account to perform node grouping.

Proximity

This clustering method is based on proximity, with edgeSDK registering edge nodes' location based on IP or GPS signal.

Network Traffic Routing

During the development of edgeSDK, mimik's team assumed a typical linkLocal network would not have a globally reachable public IP. So edgeSDK provides network traffic routing, allowing a linkLocal node to always be discoverable within or across networks.

On mimik's edgeSDK edge-cloud computing platform, each linkLocal network contains a supernode that is responsible for establishing a tunnel to the internet, and supernode is responsible for routing network traffic from the internet to other nodes within or across networks. We call this the SEP (Signaling Endpoint).

If any particular edge node in the linkLocal cluster is serving huge amounts of data, making it inefficient for it to be reached through the SEP, this particular edge node can request a BEP (Bearer Endpoint). A BEP is a private tunnel that allows the traffic to go directly to a particular edge node, just like a private VPN.

As illustrated above, in order for edge node 1 to talk to edge node 2, edge node 1 can either use a SEP or BEP.

The main difference between a SEP and a BEP is that:

A SEP is provided to the supernode for inter-cluster network communication.
A BEP is provided to one edge node for inter-cluster network communication to another edge node in different cluster bypassing supernodes and SEP.

The entire use case is driven by the amount of traffic that the microservice serves on edge node 2. If an edge microservice on edge node 2 is serving an image (< 1 MB), as an example, the traffic will put load on the supernode because all image requesting API traffic on SEP needs to be routed to edge node 2. On the other hand, if the traffic is going through a BEP, the traffic will go directly from the BEP provider to the edge node itself. Furthermore, the establishment of a BEP requires a request to be made by the edge node through microservice API calls.

Therefore, for a typical use case of edge node 1 calling a traffic-hungry API to edge node 2, mimik recommends the following procedure:

  1. Prior to calling the intended traffic-hungry microservice API, edge node 1 uses the SEP to reach edge node 2 by calling a bootstrapping API.
  2. Once the request reaches the bootstrapping API on edge node 2, it requests the creation of a BEP, and then passes the BEP address back through the response to the bootstrapping API.
  3. edge node 1 uses the BEP's address to make the traffic-hungry microservice API call directly.
  4. edge node 1 can then cache the BEP's address and continue to use it for subsequent communication.

Javascript Serverless Microservice

edgeSDK provides developers with a way to develop their own edge microservices using a serverless architecture. Developers do not need to think about server and deployment issues. Instead, they just have to focus on creating microservices, and then deploy them on edge devices.

Need more help?

Feel free to contact us on stack overflow or send us a question via our support page if you have any questions.

Was this page helpful?