Hybrid edgeCloud concepts
mimik Hybrid Edge Cloud (HEC) brings the flexibility and scalability of central cloud computing to almost any computing device including PCs, mobile phones, game consoles, IoT devices, smart routers, smart gateways, etc. The platform provides all the cloud services like clustering, network traffic routing, serverless microservice hosting, container technologies, OpenID authorization, network bootstrapping and private network tunneling, etc.
Elements of mimik HEC
The HEC platform uses various SDKs and backend services to provide its benefits to the developer community. The main elements are:
mimik edge SDK provides Discovery, Connection, and Communication (DCC) among devices, both on physical and microservice levels:
Node and service discovery: auto-discovery and auto-routing for all nodes with mimik edgeSDK in local and global network(s)
Node and Service connection: ad-hoc edge-cloud of nodes form a self-organizing cluster
Light container: microservices runtime environment to allow remote/local load of microservice images, start, stop of microservices
Sidecar pattern: enabling frontend application decomposition to abstract certain functionalities (e.g. networking, load balancing, authentication, etc.) into a sidecar and making API calls versus dealing with libraries and complexity of cross OS support.
The mimik edgeCloud Backend
The mimik backend services are hosted on servers reachable through internet and provide necessary services to support edge nodes across edge clouds. A hybrid edge cloud is defined as a collection of nodes, each with a globally unique ID, based on context or scope.
The major elements of the mimik cloud backend are (please include only those elements that the developers need to know about):
- mDS: mimik Discovery Service
- mSS: mimik Signaling Service
- SEP: Signaling End-Point (deployed dynamically and on demand)
- BEP: Bearer End-Point (deployed dynamically and on demand)
- mID: Identity Service, using third party SaaS provider
- mST: security token authentication/authorization
Clustering of Nodes
Clustering is the virtual grouping of edge nodes based on three possible scopes
This clustering method groups the nodes attached to a connected local network to create a virtual group. One of the edge nodes in the cluster is selected automatically as the knowledge holder of the cluster and is called the Supernode.
The Supernode does not have access to the bearer data of other nodes and only stores identification information about other edge nodes in the linkLocal cluster and is responsible for routing control-based networking data to other nodes in a linkLocal cluster.
This clustering method uses the end user's account to perform node grouping. All nodes registered with the same email address will become part of the cluster.
This clustering method is based on proximity. All nodes reporting to be in the proximity of one another (based on GPS or other proximity information) are grouped into the same cluster.
Network Traffic Routing
The mimik HEC platform assumes that computing devices may not have a globally reachable public IP address. Therefore, the platform provides network traffic routing, allowing all nodes to discover other nodes within or across networks.
On mimik's HEC platform, linkLocal clusters automatically elect one node as the supernode which is responsible for establishing communication to the internet (if needed). The 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:
- 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.
- 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.
- edge node 1 uses the BEP's address to make the traffic-hungry microservice API call directly.
- edge node 1 can then cache the BEP's address and continue to use it for subsequent communication.
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.
Was this page helpful?