Edge Computing nodes: What will they look like and why?
[Recently, we had the opportunity to present our (Cirrus360’s) thoughts on edge node design to edge computing thought leaders at the excellent Spring workshop of the Open Edge Computing initiative in Carnegie Mellon University. Below are some of the highlights from that presentation and related discussions.]
From all the recent buzz around edge computing, and early edge deployments that are underway, one question remains predominant. Paraphrasing a question from the book How Will You Measure Your Life: What job would you hire the Edge for? The potential “edge-native” applications are wide ranging: the headliners such as mobile and cloud gaming, augmented and virtual reality applications, safety and surveillance in smart cities, to customer engagement in smart retail, assisted and autonomous driving, autonomous drones, and defect detection services and quality control in smart manufacturing. (Look out for Prof. Satya’s upcoming paper: “The Seminal Role of Edge-Native Applications” Satyanarayanan, M., Klas, G., Silva, M., Mangiante, S. Proceedings of IEEE Edge 2019, Milan, Italy, July 2019.)
All such “edge-native” or “edge-assisted” applications will be driven by the need for ultra low latencies, managing data volume, and/or data privacy concerns. The type of edge deployments and related services that are taking shape fall under three main categories: (1) Telco edge or Multiple access edge computing (MEC) driven by operator offerings targeted to developers, (2) Cloud edge services such as from Microsoft Azure, AWS, Packet, and Cloudflare, (3) Private edge deployments seen today in enterprises such as in the industrial IoT segment.
However, the shape and size of each deployment will depend on the return on investment to the business owner or developer, in the context of total cost of deployment encompassing bandwidth, storage, and compute costs. Just as the shape and size of each deployment will vary based on use case, so too will the corresponding edge node (or edge computing unit). Edge nodes will range from smart edge gateways, to ruggedized outdoor nodes, to on-premise storage heavy nodes, to edge data center servers [open19]. In the case of edge nodes, one size will definitely NOT fit all!
Following are some of the design considerations that are driving edge node design:
(1) What kind of edge network or service out of the three main categories listed above will the node be part of? This consideration will drive connectivity choices such as 4G (or 5G!) or private LTE or WiFi for local and cloud connectivity of the node.
It will also drive the software infrastructure that the node will need to integrate such as MEC or a Akraino blue print or software stack for enterprise IoT, privacy and security features, and multi-tenancy solutions.
(2) What kind of workloads? Edge-native applications are primarily driven by the shifting data gravity to the edge such as from sensors, cameras, Lidars, and others. Consequently the workloads for this class of applications are related to pre-processing or processing this data, leading to a finite set of specialized workloads e.g. machine vision, time series data analytics, deep learning inference, signal processing, and similar.
Most of these workloads benefit significantly from special purpose accelerators such as FPGAs, GPUs, and ASICs to meet performance/ watt and performance/ cost goals. At Cirrus360 we are focusing on using FPGAs in the design of our edge computing unit, EdgeSense. (Look out for our future blog post on: When are FPGAs a good choice for edge nodes?)
What is important in this context is what will the node’s compute capabilities look like to developers? Especially, how and via what kind of APIs would these accelerators be offered?
(3) Data handling: Data source interfaces, security and privacy, storage driven by volume and life span, data organization. At Cirrus360 we recognize that how the data is processed across end-points, edge, cloud, as well as organized and stored is a big part of edge computing. We are relying on partners who are experts in this area to help us address this.
(4) Decisions driven by the data processing: Edge will exist to trigger low latency decisions and consequently edge nodes will need the right interfaces to implement such decisions whether autonomously or with human-in-the-loop.
(5) Deployment and operation of a large number of such nodes at scale. In our opinion, this is one of the most important aspects of edge deployments and edge nodes will need to provide the right support for this purpose.
Above are some of the issues we are noodling on at Cirrus360. Our current focus is driven by our SBIR award (in collaboration with Rice University) from the Department of Energy: EdgeSense™: Smart Sensors and FPGA-based Heterogenous Edge Computing Unit, which focuses on incorporating edge computing as part of high-performance computing use cases. From there on, we are extending our scope to practical edge use cases in smart manufacturing and heavy equipment segments. Please reach out if you have a Edge use case and are interested in engaging in a pilot with Cirrus360 EdgeSense.
— Chaitali Sengupta (Founder, Cirrus360)
