All Tech Field Day Podcast

Edge Computing is a Melting Pot of Technology

Edge computing is one of the areas where we see startup vendors offering innovative solutions, enabling applications to operate where the business operates rather than where the IT team sit. This episode of the Tech Field Day podcast focuses on the melting pot of edge computing and features Guy Currier, John Osmond, Ivan McPhee, and host Alastair Cooke, all of whom attended the recent Edge Field Day in September. To accommodate the unique nature of the diverse and unusual locations where businesses operate, many different technologies are brought together to form the melting pot of edge computing. Containers and AI applications are coming from the massive public cloud data centres to a range of embedded computers on factory floors, industrial sites, and farm equipment. ARM CPUs, sensors, and low-power hardware accelerators are coming from mobile phones to power applications in new locations. Enterprise organizations must still control and manage data and applications across these locations and platforms. Security must be built into the edge from the beginning; edge computing often happens in an unsecured location and often with no human oversight. This melting pot of technology and innovation makes edge computing an innovative part of IT.

Apple Podcasts | Spotify | Overcast | Amazon Music | YouTube Music | Audio

Edge Computing is a Melting Pot of Technology

The edge computing landscape sometimes feels like a cross between the public cloud and ROBO, yet edge computing is neither of these things. The collection of unique drivers bringing advanced applications and platforms to ever more remote locations requires a unique collection of capabilities. Edge computing is a melting pot of existing technologies and techniques, with innovation filling the gaps to bring real business value. 

The original AI meme application, Hotdog or Not, has become a farming application, Weed or Crop. An AI application runs on a computer equipped with cameras and mounted to a tractor as it drives down the rows in a field, identifying whether the plants it sees are the desired crop or an undesirable weed. The weeds get zapped with a laser, so there is no need for chemical weed killers as the tractor physically targets individual pest plants. The AI runs on a specialized computer designed to survive hostile conditions on a farm, such as dust, rain, heat, and cold. The tractor needs some of the capabilities of a mobile phone, connectivity back to a central control and management system, plus operation on a limited power supply. Is there enough power to run an NVIDIA H100 GPU on the tractor? I doubt it. This Weed vs Crop AI must run on a low-power accelerator on the tractor. Self-driving capabilities get melted into the solution; a tractor that drives itself can keep roaming the field all day. Freed from the limitations of a human driver, the tractor can move slower and may even use solar power for continuous operation.

There is an argument that the edge is the same as the cloud, a tiny cloud located where the data is generated and a response is required. This often has a foundation in attempts to solve edge problems by being cloud-first and reusing cloud-native technologies at edge locations. From the broader business perspective, cloud and edge are implementation details for gaining insight, agility, and profit. The implementation details are very different. Simply lifting methodologies and technologies from a large data centre and applying them to every restaurant in your burger chain is unlikely to end well. Containerization of applications has also been seen as a cloud technology that is easily applied to the edge. Containers are a great way to package an application for distribution, and the edge is a very distributed use case. At the edge, we often need these containers to run on small and resource-limited devices. Edge locations usually have little elasticity, which is a core feature of public cloud infrastructure. Container orchestration must be lightweight and self-contained at the edge. Management through a cloud service is good, but disconnected operation is essential.

Surprisingly, edge locations also lack the ubiquitous connectivity part of the NIST cloud definition. Individual edge sites seldom have redundant network links and usually have low-cost links with low service levels. Applications running at an edge location must be able to operate when there is no off-site network connectivity. The edge location might be a gas station operating in a snowstorm; the pumps must keep running even if the phone lines are down. This feels more like a laptop user use case, where the device may be disconnected, and IT support is usually remote. Device fleet management is essential for edge deployments. A thousand retail locations will have more than a thousand computers, so managing the fleet through policies and profiles is far better than one by one.

Security at the edge also differs from data centre and cloud security; edge locations seldom have physical security controls. Even our staff working for minimum wage at these locations may not be trusted. The idea of zero trust gets melted into many edge computing solutions. Validating every part of the device and application startup to ensure nothing has been tampered with or removed. Zero trust may extend to the device’s supply chain when sent to the edge location. Many edge platform vendors pride themselves on the ability of an untrained worker to deploy the device at the edge, a long way from the safe-hands deployments we see in public cloud and enterprise data centres. 

Edge computing has a unique set of challenges that demand multiple technologies combined in new ways to fulfil business requirements. This melting pot of technologies is producing new solutions and unlocking value in new use cases. 


Podcast Information

Alastair Cooke is a Tech Field Day Event Lead, now part of The Futurum Group. You can connect with Alastair on LinkedIn or on X/Twitter and you can read more of his research notes and insights on The Futurum Group’s website.

John Osmon is a consultant and a network designer / coordinator. You can connect with John on Twitter or on LinkedIn and check out his writing on Miscreants in Action.

Guy Currier is the VP and CTO of Visible Impact, part of The Futurum Group. You can connect with Guy on X/Twitter and on LinkedIn. Learn more about Visible Impact on their website. For more insights, go to The Futurum Group’s website.

Ivan McPhee is a Senior Security and Networking Analyst at GigaOm. You can connect with Ivan on LinkedIn and on X/Twitter. You can learn more about his work on the GigaOm website.


Thank you for listening to this episode of the Tech Field Day Podcast. If you enjoyed the discussion, please remember to subscribe on YouTube or your favorite podcast application so you don’t miss an episode and do give us a rating and a review. This podcast was brought to you by Tech Field Day, home of IT experts from across the enterprise, now part of The Futurum Group.

About the author

Alastair Cooke

I am self-employed consultant and writer based in New Zealand. Much of my work is communicating about how IT infrastructure works and what it means for IT professionals. Outside of work I’m datacenter and VMware focussed, having created the AutoLab which is a free tool to simplify the creation of a vSphere test or training lab.

Leave a Comment