The mimik edgeSDK brings the flexibility and scalability of the cloud computing to the edge. As a typical optimization strategy by performing data processing at the edge of the network (edge computing), we believe by bringing cloud technology to the edge, this could further help realizing true potentials of edge computing. And mimik calls this computing concept as edge-cloud computing.
The mimik edgeSDK provides edge-cloud computing platform services that offers cloud-platform-like solutions to the edge, such as clustering, network traffic routing, serverless microservice, container technology, and OpenID Authorization. Furthermore, we also provide mimik backend services to aid edgeSDK edge computing platform in areas such as bootstraping (mDS), and private network tunneling (mSS).
The concept of turning all computing devices into edge nodes are the fundamental building blocks of mimik edge-cloud computing technology.
Each computing device that runs edgeSDK is being defined as an edge node that takes a role in the network depends on the host platform constraints and its capability of offering computing power to edgeSDK edge-cloud computing ecosystem.
Clustering is division of the network into different virtual groups, based on rules to allocate the edge nodes to different networks and edgeSDK provides three ways of clustering.
This clustering method is based on utilizing the connected local network to create a virtual group. One of the edge node in the cluster is the knowledge holder called the Supernode.
The Supernode stores the knowledge of identity of other edge nodes in the linkLocal cluster. Supernode is selected based on an election algorithm.
Currently, the Supernode is also responsible for routing control-based networking data to other nodes in this linkLocal cluster.
This clustering method is based on utilizing the end user's account to perform the grouping.
This clustering method is based on proximity, edgeSDK registers edge node's location based on its IP or GPS signal.
Network Traffic Routing
During the development of edgeSDK, mimik's team assumes a typical linkLocal network does not have a globally reachable public IP. So edgeSDK provides network traffic routing technology, which allows a linkLocal node is always discoverable within or across network.
In mimik's edgeSDK edge-cloud computing platform, each linkLocal network contains a proxy node (typically is also the supernode) that is responsible to establish a tunnel to the internet. And this proxy node 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 amount of data, and thus it is inefficient 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 going directly to a particular edge node.
As the above diagram illustrates, in order for edge node 1 to talk to edge node 2, edge node 1 can either use SEP or BEP. The difference is that SEP is provided by the supernode/proxy node, but the BEP is provided directly to the edge node 2 itself. The entire use case is driven by the amount of traffic that the microservice serves on edge node 2. If the microservice on edge node 2 is serving a picture for example, the traffic will put load on the supernode/proxy node because all traffic from the SEP needs to be routed to edge node 2. On the other hand, if the traffic is going through BEP, the traffic will go directly from the BEP provider to the edge node itself. Furthermore, the establishment of BEP requires a request being made on the edge node through microservice API calls.
Thus for a typical use case of edge node 1 calling an traffic-hungry API to edge node 2, mimik recommends the following procedure:
- Prior to call the the intended traffic-hungry microservice API, edge node 1 uses SEP to reach edge node 2 by calling some-kind of bootstrapping API.
- Once the request reaches the bootstrapping API on edge node 2, it requests a BEP creation, and then passes the BEP address back through the response to the bootstrapping API.
- Edge node 1 uses BEP address to make the traffic-hungry microservice API call directly.
- Edge node 1 can then cache the BEP address and continue using the BEP to perform subsequent communication.
The edgeSDK provides developer a way to develop their microservices using serverless architecture. Like serverless architecture on the cloud, now at the edge, developer does not need to think server and deployment issues. Instead, they just have to focus on creating microservices, and then deploy them on edge devices.