Like any kind of large-scale computing system deployment ever, the short answer to the question “what should my fog compute deployment look like” is going to be “it varies.” But since that’s not a particularly useful piece of information, Cisco principal engineer and systems architect Chuck Byers gave an overview on Wednesday at the 2018 Fog World Congress of the many variables, both technical and organizational, that go into the design, care and feeding of a fog computing setup.
Byers offered both general tips about the architecture of fog computing systems, as well as slightly deeper dives into the specific areas that all fog computing deployments will have to address, including different types of hardware, networking protocols, and security.
Compute options in fog settings
Computation in fog settings often has multiple processor types, so it’s a heterogeneous environment. RISC/CISC CPUs, as made by ARM/Intel, give great single-thread performance and a high degree of programmability. "They’re always going to have an important place in fog networks, and almost every fog node will have at least a couple of cores of that class of CPU," Byers said.
They’re far from the only options, however. Field-programmable gate arrays can be helpful in use cases where custom datapaths are used to accelerate workloads, and GPUs – as seen most commonly in gaming systems, but also in increasing profusion in the high-performance computing world – are great at handling tasks that need a lot of parallel processing.
"Where a good RISC or CISC CPU may have a dozen cores, a big GPU may have a thousand cores,” he said. “And if your system and algorithms are amenable to parallel processing, GPUs are a very inexpensive and very power-efficient way to get lots and lots of bang for the buck.”
Finally, Tensor processing units, optimized to make machine learning and AI-based tasks easier, have obvious applications for applications that rely on that type of functionality.
Storage in fog computing
There’s a hierarchy of storage options for fog computing that runs from cheap but slow to fast and expensive. At the former end, that option is network-attached storage. A NAS offers huge storage volumes, particularly over a distributed network, but that means latency times measured in seconds or minutes. Rotating disks could work well for big media libraries or data archives, according to Byers, while providing substantially better response times.
Further up the hierarchy, flash storage, in the form of regular SSDs, provides much the same functionality as a spinning platter, with the well-known tradeoff in increased price-per-GB for much faster access times. That could work best for fast bulk storage, though Byers also notes that there are concerns about access speeds dropping off after a large enough number of read/write cycles.
“After you write to a given address in the chip more than about 2,000 times, it starts getting harder to reprogram it, to the point where, eventually, you’ll get write failures on that sector of flash drive,” he said. “So you have to do a thing called layer leveling across the flash array, so that you write all of the addresses in the array about the same number of times – many times, the flash drive will manage that for you.”
Local flash chips – those not set up in SSD-like arrays – are a good solution for security keys, tables and log files, and at the most expensive end of the spectrum, there’s main memory. This is best suited for popular content, in-memory databases, and so on.
Network options for fog computing
No such easily digestible hierarchy exists in the profusion of networking options available to fog architects, which are obviously split into wired and wireless categories, with the latter further bifurcated into licensed and unlicensed varieties.
Byers offered less concrete guidance on this score, saying “choose the ones that make sense to you.” Wireless tends to be inexpensive and low-impact, and really the only option for a fog deployment that has to talk to mobile devices.
Licensed wireless tends to be slightly better controlled, with less potential interference from outside sources, but licensing and/or usage fees will obviously apply.
According to Byers, however, wired tends to be preferable to wireless, where possible, because they’re immune to interference and they don’t use RF spectrum.
“We like wireline networks, especially as you get closer to the cloud, because wireline networks tend to have more bandwidth and a lot less operational expense,” he noted.
Fog computing software options
The key point where software is concerned, according to Byers, is modularity. Fog nodes linked together by standards-based APIs let users replace different components of their software stack without disrupting the rest of the system unduly.
“The modular software philosophy really has to be compatible with the software development process,” he said. “So if you’re using open source, you might want to partition your software modules so that they’re partitioned in the same way as your open source distribution of choice.”
Similarly, if agile development methods are being used, choosing the size of the “chunk” that users break off can let them reprogram a component in a single development cycle.
Fog computing security
Some fog systems – ones that aren’t monitoring or controlling anything particularly critical – have “fairly modest” security requirements, according to Byers. Others, including those that have actuators capable of strongly affecting the physical world, are mission-critical.
Reactors, elevators, aircraft systems and the like “are going to kill people if they’re hacked,” so securing them is of the utmost importance. As well, government regulation is likely to impact those systems, so that’s another facet for fog designers to keep an eye on.
Energy efficiency can come into play quickly in large enough fog computing systems, so it behooves designers to include low-power silicon, ambient cooling, selective powerdown modes wherever possible.
In a similar vein, Byers noted that functionality that doesn’t actually need to be a part of the fog setup should be moved to the cloud wherever possible, so that the cloud’s advantages of virtualization, orchestration and scalability can be realized to their fullest potential.