Purpose
The purpose of this document is to describe the various components that make up the edgeEngine Backend Services
Intended Readers
The intended readers of this document are software developers, system engineers, application architects, deployment personnel and other technical professionals who want to understand the details of working with edgeEngine Backend Services.
What You Will Learn from this Document
After reading this document you will:
- Understand the 7 components that make up the edgeEngine Backend Services
- Understand the role that each component plays in the operation of the edgeEngine Backend Services
What You Need to Know Before You Start
In order to get full benefit from reading this document we expect the reader to have a prior understanding of the following:
- The basics of edge computing architecture as opposed to traditional client-server computing via the internet.
- How the edgeEngine Runtime makes is to that any network aware device such as a cell phone or mobile table can become part of cluster of device nodes running the edgeEngine Runtime.
Understanding edgeEngine Backend Services
edgeEngine Backend Services provide necessary services to support clusters of edgeEngine nodes running across a hybrid edge cloud. These backend services are hosted on servers that are reachable through the internet.
| What is a hybrid edge cloud? |
|---|
| A hybrid edge cloud is defined as a collection of nodes, each with a globally unique ID, based on context or scope. A given node may be at any time a member of any or all three cluster types: user account cluster, network cluster or proximity cluster. |
The following table describes each of the edgeEngine Backend Services.
| Service | Description |
|---|
| mDS | mimik Discovery Service | The mDS has the intelligence to form clusters and report the overall status of the clusters as well as the nodes within them. Once a cluster is formed, any new node registers with the supernode. A supernode reports the status of its constituent nodes to the mDS. |
| mSS: | mimik Signaling Service | The mSS provides APIs to launch and track SEP and BEP components. |
| SEP | Signaling End-Point | [TO BE PROVIDED] |
| BEP: | Bearer End-Point | [TO BE PROVIDED] |
| mID | Identity Service, | The mimik identity management service is a SaaS based solution based on OAuth2.0, which resides in the public cloud and creates and maintains the authentication profile. |
| mST | security token authentication/authorization | The mST is a SaaS based solution based on OAuth2.0 that delivers tokens to services making requests to other services within an edgeEngine cluster. |
| mIT: | Registry Service | The mIT is a SaaS solution which resides in the public cloud. the mIT maintains the list of all the backend microservices and the clusters to which they belong. |
The following sections describe the details of each service.
mimik Discovery Service (mDS)
The mDS has the intelligence to form clusters and report the overall status of the clusters as well the nodes within them. Once a cluster is formed, any new node registers with the cluster's supernode that subsequently informs mDS via the supernode. In the interest of reducing traffic for scalability, updates from the supernode to the mDS happen in an opportunistic fashion and only when a change occurs in the cluster.
The other most important function of the mDS is the reachability test to a supernode. When a supernode registers itself, the mDS tests for reachability. The supernode might be behind a firewall and while it could initiate a call to mDS, the mDS or other external nodes might not be able to imitate a call to the supernode. In such cases, the mDS will request the mimik Signaling Service (mSS) to dynamically deploy a Signaling End-point (SEP) for the cluster. The mDS returns the SEP address to the supernode. Further descriptions of SEP and BEP are below.
The mDS holds a complete inventory of nodes and cluster profiles. This inventory includes details of computing resources on all the nodes, status of each node, location of each node, services available on each node, the end-to-end network topology to reach each node and the clusters, the reachability of the clusters, the availability of resources, and other pertinent information. In other words, mDS has complete visibility to all resources across the network and can supply this information to dynamically deploy services on any available resource within the network real-time. To make things easier for developers, standard amazon semantics are used for exposing the resources in a similar fashion as a central cloud resource.
mimik Signaling Service (mSS)
The mSS provides APIs to launch SEP and BEP components. The mSS keeps track of the existing BEP and SEP in a cluster of mSS and provides information needed to properly load balance the BEP and SEP in the cluster of mSS. In order to provide optimal latency based on where the BEP and SEP are needed, the mSS are independently geo distributed.
Parts of the mSS and the mDS live both on the backend and on edge nodes. Link-local network proxies in each cluster are assisted by mSS via SEP or BEP. Also, the supernode of a cluster is assisted by mDS. The mimik architecture departs from the traditional notion of service in the cloud - client on the edge structure. The value of the mimik architecture comes from the distribution of services over the entire range of the digital landscape, from central cloud all the way to the edge nodes.
The mSS are geo-distributed independently in order to provide optimal latency based on where the BEP and SEP are needed.
Signaling End-Point (SEP)
The SEP is used for signaling communication while BEP is used for data communications and jointly they assist the nodes to set up tunneling opportunistically to increase signaling and data bandwidth efficiency. SEP and BEP are deployed based on parameters such as time to live, number of concurrent connections, and communication protocols (HTTP, SSH, Web socket or UDP tunneling). If desired, end points can be deployed on available computing resources within the closest proximity of the cluster.
After signaling is established via an interaction between SEPs, a BEP is installed on each node in the conversation, for the bulk of the exchange between the two nodes. The flexibility of separating signaling, and bearer channels allows the creation of service-specific BEPs that are not restricted to HTTP based service delivery
Bearer End-Point (BEP)
The BEP is used for data communications between nodes. The BEP works with the SEP to set up tunneling opportunistically between nodes to increase signaling and data bandwidth
mimik Identity Service (mID)
The mimik identity management is a SaaS based solution based on OAuth2.0, which resides in the public cloud and creates and maintains the authentication profile. The mimik platform performs authorization (token generation and management) for the token holder. The token holder can be the edgSDK, the microservice using the edgeSDK, the application developer using the edgeSDK as well as the end-user of the application. The token is used to verify the credentials, legitimacy of the token holder, and authorizing access to all mimik backend services through the use of Jason Web Tokens (JWT) and a subset of standard “claims” defined in for verifying the identity of the token holder.
mimik Server Token service (mST)
The mST is a SaaS based solution based on OAuth2.0. It delivers tokens to services making requests to other services. It resides in the public cloud and issues service tokens according to a system map on mST. Moreover, mST implements client_credentials and refresh_tokens flow. When a microservice needs to invoke another microservice, it either already has a valid token and therefore can make the request directly or it requests a token which includes a list of permissions (scopes). The receiving service will validate the token signature and scopes in order to fulfill the request. Generally, these service to service tokens are short lived.
mimik IT repository (mIT)
The mIT is a SaaS solution which resides in the public cloud and maintains the list of all the backend microservices and the clusters to which they belong. Mostly used for administrative purposes, mIT maintains the cluster knowledge and allows clusters to be self-managed for configuration purposes. The mIT provides geo-located lists of clusters (configuration) that can be used by other services (like mDS) to identify the mSS to invoke a BEP or a SEP when required.