10 ways fog computing extends the edge

10 ways fog computing extends the edge

A look at how fog extends edge computing functionality in IoT and 5G ecosystems — and how it bridges the gap between the cloud and what needs to be analyzed locally.

The role of fog computing as the necessary architecture to enable IoT, 5G and embedded AI is getting clearer, but questions remain about the linkage between fog and edge.  The bottom line: Fog and edge are synergistic.

Fog is superset of Edge Computing

Fog is superset of Edge Computing.

At the OpenFog Consortium, we describe fog computing as bridging the continuum from cloud to things.  It’s a continuum because fog overlaps cloud and things and fills the computing gap in between.  Fog provides the missing link in what data needs to be pushed to the cloud, and what should be analyzed locally – at the edge.  In the IT and IoT food chain, we describe it as edge is to fog, as apple is to fruit.

Although there is some overlap, a clear understanding of the relationship between fog and edge is necessary to design functional, efficient IoT and 5G architectures and to enable their productivity.  In that spirit, here are 10 ways that fog architecture leverages and extends edge capabilities:

Although there is some overlap, a clear understanding of the relationship between fog and edge is necessary to design functional, efficient IoT and 5G architectures and to enable their productivity.  In that spirit, here are 10 ways that fog architecture leverages and extends edge capabilities:

  1. Compute Distribution and Load Balancing. Many edge architectures employ a strategy of placing servers, apps or small clouds at the edge.  Fog provides a broader system-level architecture that also incorporates tools for distributing, orchestrating, managing and securing resources and services across networks. This provides a balance of sophisticated computation, networking, and storage capabilities, and support for hetereogeneous environments on any node (e.g., CPUs, GPUs, FPGAs and DSPs for compute).
  1. Hierarchical Networking. Edge is often optimized for a single type of network resource at the network edges, such as edge gateways, routers, switches, or licensed spectrum wireless networks.  Fog supports a physical and logical network hierarchy of multiple levels of cooperating nodes, supporting distributed applications.  Fog nodes extend the edge with support for north-south, east-west and diagonal connectivity, including interfaces between edge and cloud. This could include, for example, analytics algorithms distributed up and down a hierarchy of nodes, or massively parallel applications that concurrently run on large peer groups of processors, or highly distributed storage systems.
  1. Universal Orchestration & Management. Edge orchestration and management are sometimes derived from specific legacy vertical practices, such as mobile network orchestration managed by the carrier.  In these situations, edge may deliver cloud capabilities but without orchestration for connecting edge nodes.  Fog orchestration and management is intended to be more universal, modern, and automated.  Fog orchestration enables resource pooling and permits interactions and collaborations between fog nodes at the same layer and at different layers in the hierarchy, which helps performance, fault tolerance, load distribution and load balancing.  Fog network management considers a life-cycle management through a distributed service orchestration layer in each fog node.  The fog architecture essentially validates IT (information technology), OT (operational technology) and CT (communications technology) approaches.
  1. Modular Architecture with Multiple Access Modes.  Edge deployments are typically based on gateways with fixed functionality. Edge architectures favor one specific access network, such as either wireless or wireline.  Fog has a highly modular hardware and software architecture, permitting every fog node to be equipped with exactly the resources its applications need, that can be dynamically configured.  Fog embraces both the licensed and unlicensed wireless spectrum, as well as copper or fiber wireline modes.
Side by side view of edge and fog architectures.

Side by side view of edge and fog architectures. Edge runs specific applications in a fixed logic location and provides a direct transmission service without data analysis. Fog works with edge to run applications in a multi-layer architecture that decouples and meshes the hardware and software functions, allowing for configuring / reconfiguring for different applications while performing intelligent transmission services with computing/storage/communication capabilities along the cloud to things continuum.

  1. Reliabilty and Resilency. Fog architectures are inherently reliable, supporting many fault tolerance, network resiliency, and fully autonomous emergency operation scenarios. If an edge devices goes down, the services it supports will often fail.
  1. Security and Privacy. By virtue of its vertical application-specific and multi-vendor nature, edge may offer uneven security protection. Fog, on the other hand, requires every fog node to include a high-assurance implementation of its Trusted Computing Base using secure hardware or hardware-supported security mechanisms and a mandatory mission-critical class protection of communication and computation security. Fog also requires the Trusted Execution Environments instantiated in the fog nodes within the same service domain, to form a distributed trusted computing platform enforcing a common set of information security and privacy policies. This distributed platform can provide on-demand security services to resource-constrained devices associated with the fog as well as offer trustworthy information processing, storage and transport throughout the device-fog-cloud continuum.
  1. Virtualization Support. Fog supports virtualization and uses enterprise and web-scale models. This provides hardware virtualization at each node level and allows loads to be moved from one node to an adjacent node if the node is down or overloaded. Edge computing looks at virtualization mainly from the perspective of distributing computing resources in a local manner per server.
  1. Workload Agility. Edge architectures are not particularly agile in environments with stringent or highly dynamic performance requirements. Fog is architected from the ground up to be a horizontal platform, capable of serving applications from all vertical markets and also applications that may fall between or span across multiple markets.  As such, fog is designed to be highly agile, allowing applications to tailor their performance attributes to their specific needs.  Application workloads can be moved up or down the hierarchy, and scale the degree of parallelism to exactly match the requirements, without wasting resources unnecessarily.
  1. Application Right-Sizing and Scalability. Fog nodes and fog networks can be right-sized for their applications more precisely than edge nodes, which are often stripped-down cloud servers.  Edge devices scale by adding more compute resources at a given location, almost like a mini-cloud, which can be problematic when scaling to support networks supporting millions of things. Fog is capable of dynamically moving computation, networking or storage tasks up and down levels of a hierarchy, or across peer nodes on the same level, or between the cloud and fog. It also enables resource pooling for enhanced scalability.  This can help fog extend the capabilities of edge for IoT applications that have environmental, power, size, or weight constraints.
  1. Mobile IoT Application Support. Fog delivers strong support for mobile IoT elements and applications; mobile fog nodes can be found on vehicles, drones, pedestrians, livestock, or portable devices and sensors of various kinds.  Fog nodes compute & communicate on devices in motion; infrastructure fog nodes can provide the first line of network functions; and deeper nodes can provide more core network functions.  Through the fog hierarchy, the nodes can be orchestrated at a system-level view.  This can greatly reduce the bandwidth that must be transmitted deeply in the network.  Edge typically doesn’t support this degree of network element placement diversity, limiting its use in remote and bandwidth constrained applications.

Why does this matter?

It’s clear that edge and fog are complementary.  It is time for us to move the conversation from “how are they different”to “how should they work together” to enable advancements in industry

For fog architects, the answer lies in where, when and how to distribute computation, communication, control and storage along the continuum from cloud to things – not only at the edge but from where data is generated to where communications, decisions, monitoring and actions take place.

At the OpenFog Consortium, our technical working groups are addressing all aspects of this continuum. The OpenFog Reference Architecture (RA), released in February 2017, provides an overview of system architectures for fog nodes and networks, and lends insight into fog-edge collaboration.

Our goal is to enable all of the architectural benefits of the cloud and to leverage the superset of elements in the fog continuum. If an implementation is run on pure edge, it may be reliant to a commodity gateway market.  Fog architecture opens up a much richer architectural canvas:  It’s an architecture that potentially can extend hardware and software leaderships well into the future of IoT and 5G.

The OpenFog Consortium

About The OpenFog Consortium

The OpenFog Consortium is a global nonprofit formed to accelerate the adoption of fog computing in order to solve the bandwidth, latency, communications and security challenges associated with IoT, 5G and artificial intelligence. It’s work is centered around creating a framework for efficient and reliable networks and intelligent endpoints combined with identifiable, secure, and privacy-friendly information flows in the Cloud-to-Things continuum based on open standard technologies. For more information, please email [email protected].

Leave a Reply

Your email address will not be published. Required fields are marked *