Architecting a SaaS enabled Edge: Governance, the missing piece of the puzzle
As discussed in this article, Edge Computing Network (ECN) can bring several benefits such as better data localization, and much lower and stable latencies, but it also poses major challenges. In contrast to the isolated cloud or on-premise infrastructure, edge devices are out in the real world with limited connectivity and physical security. This leads to an exponentially larger management overhead. In this post, I review different computation models and sketch a potential path towards a pragmatic ECN.
Computation Models
A mature computation platform such as cloud offers much more than just the ready to be rent-out resources. To be more specific, there are three models for computing services: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). IaaS manages the infrastructure with high-level APIs used to dereference details of the underlying resources. PaaS helps developers to build custom apps without the complexity of dealing with the infrastructure. SaaS provides software that is hosted and is ready to be used.
The Path toward SaaS
To reach the Application Level (SaaS) in ECN, a number of mechanisms are required to ensure the ease of running applications on such a platform so that this model can be competitive to that of Cloud. However, the management and governance of an ECN, due to its distributed nature, is a very complicated task. As mentioned here, the main aspects of edge network governance are:
- Self-organization, Fault Tolerance, and Reliability
- Service orchestration in ad-hoc infrastructure setup
- A common interaction language (Programmability)
- Trust & Incentivisation (Control & Transparency)
In an ad-hoc infrastructure setup, devices and servers (nodes) need to be set up by pooling them upon demand, creating computing systems of different capabilities. In other words, instead of locating resources individually and pre-deciding about which set of devices should perform the computation, a virtual pool of devices should be created on the spot, considering the consumer policy and availability of the resources.
By this, nodes are auto-selected at the edge of the network and can be used to deploy the in-hand applications in a self-organized way. The network needs to manage this activity and lease resources for a predefined duration of time. Moreover, it should guarantee the correctness of the results. To do so, there are some aspects that need to be taken care of :
- Assuring that committed resources do what they are tasked to do — i.e. determining faulty nodes.
- Assuring that the deployed software does as expected — i.e. monitoring application behavior
- Enabling fault-tolerance — i.e. recovery plan for nodes and applications
To maximize the use of such dynamic and open infrastructures, developers should be equipped with a common interface, commanding the network to build distributed applications. Users will be able to deploy applications in the target area and benefit from the software without unnecessarily movement of the data or it’s exposure to the outside world.
Even a self-orchestration ECN needs to keep nodes motivated to participate as part of the network. Trust and incentivization are typical problems of many peer-to-peer setups. Distributed Ledger Technologies (DLT) and their corresponding communities are actively trying to solve these issues. To have the ultimate trust-enabling solution in place, a distributed ledger can enable a governance layer that brings transparency, incentivization and eases the provability.
Needless to say that the commonly known implementation of DLT, Blockchain, will not satisfy the high throughput requirement of ECN. To deliver that, more scalable implementations should be adopted. Also, additional mechanisms should be acquired to protect the network from various attacks. These matters require separate extensive discussions.
Architecting an ECN as proposed, in fact, will lead to a marketplace for trading (unutilized) computation power, storage on the edge/fog nodes. Furthermore, it serves as a vehicle, fine-tuned for the deployment of the distributed applications. This way, the interactions between peers are governed in a decentralized self-organized manner. It also gives absolute flexibility to the consumers to choose the right service given their requirements such as latency, cost, reliability, performance, and security.
This enables enterprises, industrial production sites, cities, or other businesses to better utilize their (unused) internal resources as part of their trusted network. It also leverages the possibility to further extend the network to publicly available near-shore nodes for additional computation power, storage, and even applications.
DISCLAIMER: This post just reflects the author’s personal opinion, not any other organization. This is not official advice. The author is not responsible for any decisions that readers choose to make.
