Fog nodes are the new ‘cool kid’ components for edge computing. However, we risk overusing them if we don’t understand their true purpose at the edge Credit: Aleksandar Pasaric Think of a fog computing node as a physical server that resides between the edge devices (thermostats, robots, in-vehicle computers) and the back-end systems, typically hosted on public clouds. The fog nodes respond to an architectural problem: too much latency to pass requests all the way back to the public cloud-based services and not enough horsepower to process the data in the edge device itself. This three-tier system adds another compute platform that is able to do some—if not most—of the back-end processing. This addresses the concern that cheaper edge devices with lower power don’t have the processing and storage power to deal with the incoming data natively. Now data can be sent to the fog node for processing, without the latency impact of going all the way back to the remote cloud services. Although fog nodes are a simple solution to a simple issue, you should understand when and when not to use them: You should use fog nodes when data that is complex or in large amounts need to be processed locally and would overwhelm the edge-based device that is consuming the data as well. In other words, you need something that responds in almost real time, such as a factory robot shutting down when the servers overheat. You want that to be instantaneous. You should use fog nodes when a human is waiting for the response to return back to the edge device. Like the need to respond to events that can’t wait, humans need to be considered near-real-time architectural components. People are too expensive to be waiting around for responses from the remote cloud systems. You should use fog nodes when you’re multiplexing data from several different types of edge devices or sending several different types of data. The fog node manages the processing of data from several edge devices at once, dealing with things such as semantic transformation of the data before sending it to the back-end cloud servers. Or the fog node can process and respond directly to the edge-based device. Basically, you should not use fog nodes unless the architecture and requirements fit the above criteria. In my book, they should be used sparingly, especially considering that they add cost and operational complexity—and another layer that can fail. Your best bet for now is to exclude them, and then figure out if you have situations where they can be of use. Related content analysis Azure AI Foundry tools for changes in AI applications Microsoft’s launch of Azure AI Foundry at Ignite 2024 signals a welcome shift from chatbots to agents and to using AI for business process automation. By Simon Bisson Nov 20, 2024 7 mins Microsoft Azure Generative AI Development Tools analysis Succeeding with observability in the cloud Cloud observability practices are complex—just like the cloud deployments they seek to understand. The insights observability offers make it a challenge worth tackling. By David Linthicum Nov 19, 2024 5 mins Cloud Management Cloud Computing news Akka distributed computing platform adds Java SDK Akka enables development of applications that are primarily event-driven, deployable on Akka’s serverless platform or on AWS, Azure, or GCP cloud instances. By Paul Krill Nov 18, 2024 2 mins Java Scala Serverless Computing analysis Strategies to navigate the pitfalls of cloud costs Cloud providers waste a lot of their customers’ cloud dollars, but enterprises can take action. By David Linthicum Nov 15, 2024 6 mins Cloud Architecture Cloud Management Cloud Computing Resources Videos