Edge Computing Patterns for Solution Architects E-Book

Ashok Iyengar

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 324

Veröffentlichungsjahr: 2024

Beschreibung

Enriched with insights from a hyperscaler’s perspective, Edge Computing Patterns for Solution Architects will prepare you for seamless collaboration with communication service providers (CSPs) and device manufacturers and help you in making the pivotal choice between cloud-out and edge-in approaches.
This book presents industry-specific use cases that shape tailored edge solutions, addressing non-functional requirements to unlock the potential of standard edge components. As you progress, you’ll navigate the archetypes of edge solution architecture from the basics to network edge and end-to-end configurations. You’ll also discover the weight of data and the power of automation for scale and immerse yourself in the edge mantra of low latency and high bandwidth, absorbing invaluable do's and don'ts from real-world experiences. Recommended practices, honed through practical insights, have also been added to guide you in mastering the dynamic realm of edge computing.
By the end of this book, you'll have built a comprehensive understanding of edge concepts and terminology and be ready to traverse the evolving edge computing landscape.

Leseprobe

Edge Computing Patterns for Solution Architects

Learn methods and principles of resilient distributed application architectures from hybrid cloud to far edge

Ashok Iyengar and Joseph Pearson

Edge Computing Patterns for Solution Architects

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author(s), nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Kunal Sawant

Publishing Product Manager: Samriddhi Murarka

Book Project Manager: Manisha Singh

Senior Editor: Nithya Sadanandan

Technical Editor: Vidhisha Patidar

Copy Editor: Safis Editing

Indexer: Pratik Shirodkar

Production Designer: Ponraj Dhandapani

DevRel Marketing Coordinator: Shrinidhi Manoharan

Business Development Executive: Debadrita Chatterjee

First published: January 2024

Production reference: 1190124

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-80512-406-1

www.packtpub.com

This book would not be possible without the unwavering support and understanding of Radha and tons of encouragement from Sameer, Siddharth, and Mythili. They collectively inspire me with their own successes. And to my newest cheerleader, Seelan, who never ceases to amaze me.

-- Ashok Iyengar

To my mentor and guide, Rob High. Thanks for the guidance, trust, and opportunity to learn about edge computing.

– Joe Pearson

Contributors

About the authors

Ashok Iyengar is an Executive Cloud Architect at IBM. As a member of the Architecture Guild, he focuses on creating solution architectures that encompass distributed computing, edge computing and AI. He follows NDSU Bison football and is eagerly looking forward to bringing generative AI to edge computing. He enjoys being a mentor, author, speaker and blogger.

I owe a debt of gratitude to my co-author, Joe Pearson, who keeps me honest. I would not have undertaken this effort if it was not for his willingness, encouragement and tireless work ethic.

Joseph Pearson has worked as a college instructor and in various media companies for over three decades, most recently as Software Architect at The Weather Channel on weather.com. He has since worked for IBM Cloud as a Strategist and then IBM Software in Edge Computing. He currently works for IBM Software’s Networking and Edge Computing unit on their open source strategy. He volunteers with the Linux Foundation as Chair of the LF Edge Technical Advisory Council (TAC) and leads the Open Horizon project. And in any spare time, he enjoys geocaching.

I would like to thank my wife and children for bearing with me as I stole time from them throughout the process of writing this book. I especially want to thank Ashok Iyengar for supporting and encouraging me to tackle working on this book when it seemed so daunting. It’s always helpful to have an experienced friend and author to collaborate with who can also be a big brother and provide frank guidance when it’s most needed.

About the reviewer

Frédéric Desbiens manages Embedded, IoT, and Edge Computing programs at the Eclipse Foundation, Europe’s largest open-source organization. His job is to help the community innovate by bringing devices and software together. He is a strong supporter of open source. In the past, he worked as a product manager, solutions architect, and developer for companies as diverse as Pivotal, Cisco, and Oracle. Frédéric holds an MBA in electronic commerce, a BASc in Computer Science, and a BEd, all from Université Laval (Québec City, Canada).

Frédéric is the author of “Building Enterprise IoT Solutions using Eclipse IoT Technologies: An Open-Source Approach to Edge Computing,” published in December 2022 by Apress (ISBN: 978-1484288818).

Table of Contents

Preface

Part 1:Overview of Edge Computing as a Problem Space

1

Our View of Edge Computing

Suggested pre-reading material

Speaking like an edge native

What is the edge?

Are the edge and the cloud extremes of the same thing?

How does edge computing bring value, and why now?

Which edge? Categorizing edges

The user edge – field-deployed compute

The SP edge – regional compute

Your computer or mine? Tactics for service deployment

Edge computing doesn’t require dedicated resources

Single device, running multiple applications simultaneously

Single device, alternating applications by schedule or purpose

Hosted edge infrastructure – applications on shared compute

Cloud-out versus edge-in

Looking deeper at cloud-out architectures

Delving into edge-in architectures

Introducing archetype patterns

What is an archetype?

The days of software creation

Deploying archetype patterns

Summary

2

Edge Architectural Components

Edge components

Functional requirements

Sensing

Inferencing

Analytics

Data

Non-functional requirements

Security

Service management and operations

Edge use cases and patterns

Edge device specifications and protocols

Architectural decisions

Grouping edge ADs

Cloud

Network

Server/cluster

Device

Summary

Part 2: Solution Architecture Archetypes in Context

3

Core Edge Architecture

Suggested pre-reading material

What is legacy IoT architecture?

A bit of history

Purpose and promise

Fundamental drawbacks

Device configuration

Rationale

Architectural element categories

Edge devices versus edge hub

Reviewing the pattern

Self-propelled inspection robot example

Containers

Disconnected operations

Summary

4

Network Edge Architecture

Definitions

NFV

NFV considerations

SDN

VNF, NFV, SDN, and edge computing

Underlay and overlay networks

Network traffic management

MEC

Network edge architecture

RAN

CSPs and hyperscalers

Sample architectures

Manufacturing scenario

Healthcare scenario

Campus network scenario

Summary

5

End-to-End Edge Architecture

IT and OT convergence

AI and edge computing

Industrial edge scenario

Manufacturing scenario

Retail edge scenario

Retail store scenario

Network slicing

Example scenario

Edge reference architecture

The cloud

The network

The edge

Edge and distributed cloud computing

Distributed cloud computing

The scenario

Summary

Part 3: Related Considerations and Concluding Thoughts

6

Data Has Weight and Inertia

Suggested pre-reading material

Data encryption

Motivations for encrypting data

Protecting data without making it difficult to use

Ensuring that data modifications are noticeable

Data storage and management

Strategies for defining and enforcing data policies

Usage options ranging from real to synthetic data

Rules of thumb for retaining data, or not

Using data to build machine learning (ML) models

The promise of foundation models

How small and efficient can we make models?

Customizing existing models for each deployment

Using general-purpose platforms rather than single-purpose applications

Connectivity and the data plane

Optimizing data availability without connectivity

Aggregating data versus keeping it distributed

Migrating data files automatically

Summary

7

Automate to Achieve Scale

Automating service delivery

DevOps

Infrastructure as code

Extending automation to the edge

Developing edge applications

Scalability with automation

Prepping an edge device

Prepping an edge cluster

Operational security

Limiting physical access

Limiting connectivity

Trusted hardware and provisioning

Trusted data

Trusted compute

Tactical Edge

Automation with AI

LLMs and generative AI

Using AI in automation

Summary

8

Monitoring and Observability

Monitoring and observability

How monitoring works

How observability works

How network observability works

Measuring to improve

Network observability example

What to measure

Real user monitoring

Network performance management

Anomaly detection

Capacity

Business outcomes

Improving edge solution

Monitoring challenges at the edge

Configuration changes at the edge

Edge application monitoring

Personas

Summary

9

Connect Judiciously but Thoughtlessly

Suggested pre-reading material

Declarative versus imperative configuration

Comparing the two approaches

What slows down application deployment on the edge?

Solutioning edge-connected networks and applications

Zero Trust or as close as you can get

Managing secrets on the edge

Zero Trust architectures in edge computing

Secure access service edge

Overlay, underlay, and shared responsibilities

The network underlay

The network overlay

Zero Trust Network Access

End-to-end encryption

Application-centric networking

Summary

10

Open Source Software Can Benefit You

Suggested pre-reading material

Open source and edge computing

Edge computing and OSS are intertwined

Do you really need to create that component?

Creating and supporting an open source program office (OSPO)

A software bill of materials is your friend

Using SBOMs to track software dependencies

The characteristics of a mature OSS project

How to nurture and assist projects you rely on

Responses to projects that stray from their mission

Common objections

Recommendations for contributing code

Let the cat out of the bag (Successfully open source your code and documentation)

Five options for open sourcing

What to open source

Summary

11

Recommendations and Best Practices

Suggested pre-reading material

Edge-native best practices as an outgrowth of cloud native

Pulling can be more secure than pushing

Application dependency resolution approaches

Deployment models for distributed edge applications compared

Making antifragile applications

Defining the terms

What are your current areas of weakness or vulnerability?

Properties of antifragile architectures

An ounce of prevention...

When things go wrong

What to avoid

Anti-patterns

How to recover, gracefully or not

Summary

Index

Other Books You May Enjoy

Preface

Edge computing as we know it has rapidly evolved from its early days as a successor to the Internet of Things (IoT). Processing data at the source has become the ultimate goal because businesses and people expect analytics insights to be available and transaction results to be cleared in real time. That includes medical analysis, money transfers, payment receipts, video inferencing, and voice recognition. All this is possible because devices have become “smart” and the communication networks are able to deliver high speed and high throughput with low latencies to these new deployments. We have seen the rise of a new paradigm of application architecture specifically designed to run in domains that are not only constrained but also widely distributed. The IT architectures facilitating these advancements are unique because of the very nature of edge computing.

If the name of the game is to get insights quickly from all the data, we have to ensure there are applications able to do that, devices that can host the applications, and a network facilitating the information flow. That is the challenge solution architects face, which is who this book is primarily written for.

Drawing from real-world deployments in large enterprises and standards proposed by edge computing community organizations, this book emphasizes practical and tested-at-scale patterns and best practices used by leading companies worldwide. The book takes the reader from edge computing terminology and concepts to simple architectures, and eventually through end-to-end industry-specific approaches. It gives several points of view and rules of thumb and provides resources and recommendations for deeper thinking and research.

Who this book is for

This book is intended for IT professionals who have created solution architectures and are looking to extend their skills to the edge computing space. It should be valuable to VPs of IT infrastructure, enterprise architects, solution architects, and SRE professionals who are familiar with cloud computing and are interested in creating an edge reference architecture or a solution architecture for a particular industry use case. The book provides common patterns from solutions implemented by customers in industries ranging from retail to telcos to manufacturing.

What this book covers

Chapter 1, Our View of Edge Computing, establishes a shared vernacular, describes infrastructure scenarios, and relies on industry conventions to ensure standard and widely compatible solutions.

Chapter 2, Edge Architectural Components, covers four roles of components in edge architectures, benefits and limitations, and functional versus non-functional requirements.

Chapter 3, Core Edge Architecture, covers managing and enabling sensors and smart devices using the Edge Device Hub pattern.

Chapter 4, Network Edge Architecture, explores transitioning to software-defined network architectures to enable digital service provider scenarios.

Chapter 5, End-to-End Edge Architecture, brings together devices, macro components, and applications to solve industry-specific challenges.

Chapter 6, Data Has Weight and Inertia, explores the data-related considerations that edge-native solutions will need to address.

Chapter 7, Automate to Achieve Scale, includes approaches that have worked at the extreme scales that edge deployments may encounter.

Chapter 8, Monitoring and Observability, covers how to ensure that a deployed edge solution is performing as designed, despite unique challenges.

Chapter 9, Connect Judiciously but Thoughtlessly, covers three connection scenarios and how application-centered approaches can address them.

Chapter 10, Open Source Software Can Benefit You, explores strategies for ensuring that open source dependencies are used optimally, and when and how an enterprise should open source their solutions.

Chapter 11, Recommendations and Best Practices, takes a wider view of the problem space and how thinking deeply about what you are doing and why can yield some surprising insights.

Images used in the book

You can find the images used in this book in the GitHub repository at https://github.com/PacktPublishing/Edge-Computing-Patterns-for-Solution-Architects.

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “If you notice closely, it is an Open Horizon environment variable, namely HZN_DEVICE_ID.”

A block of code is set as follows:

#!/bin/sh # Simple edge service while true; do     echo "HZN_DEVICE_ID says: Hello from Packt!"     sleep 5 done

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “The following code snippet is a very simple Hello World service that outputs Hello from Packt every five seconds.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Edge Computing Patterns for Solution Architects, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781805124061

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:Overview of Edge Computing as a Problem Space

To build a shared understanding, we lay the groundwork and survey the territory in the first two chapters. Since the concepts and terminology in edge computing can be overloading, it’s important to explain exactly what is meant when we elucidate our concepts, problems, and solutions. The first two chapters in the book aim to provide clarity and a common foundation that will be built on in Parts 2 and 3. This part begins with how to think and talk about edge computing grounded in context. It then delves into the various components, describes their purposes, and shows how they relate to others and where they best fit.

This part has the following chapters:

Chapter 1, Our View of Edge ComputingChapter 2, Edge Architectural Components

1

Our View of Edge Computing

One of the first challenges when discussing edge computing between IT professionals is establishing a shared vernacular. In the authors’ experience, professionals in this space differ in how they describe the goals, methods, available tools, and deployment targets/operating environments. We’ve also found that, due to experiences and even generational distinctions, some fundamental assumptions may be at play. By agreeing on a definition of terms at the outset, we avoid misunderstandings and talking past each other.

In this chapter, we will start by describing various edge computing scenarios from an infrastructure point of view, moving from cloud to far edge based on our experiences, research, and available de facto standards. Along the way, we compare and contrast different points of view that will affect architectural choices you can make, such as edge computing versus distributed computing and the network edge versus the enterprise edge.

We will rely on conventions covered in the Suggested pre-reading material section, such as State of the Edge annual reports and LF Edge whitepapers. By the end of the chapter, you should have the shared vocabulary and a wider perspective needed to engage in fruitful conversations on edge computing with software architects and other IT professionals.

In this chapter, we will cover the following main topics:

Speaking like an edge nativeWhich edge? Categorizing edgesYour computer or mine? Tactics for service deploymentCloud-out versus edge-inIntroducing archetype patterns

Suggested pre-reading material

State of the Edge Report 2023 (The Linux Foundation)

(https://stateoftheedge.com/reports/state-of-the-edge-report-2023/)

From DevOps to EdgeOps: A Vision for Edge Computing (Eclipse Foundation) (https://outreach.eclipse.foundation/edge-computing-edgeops-white-paper)Sharpening the Edge – Part 1 (LF Edge) (https://lfedge.org/wp-content/uploads/sites/24/2023/12/LFEdge_Akraino_Whitepaper2_v1_PrePrint.pdf)Sharpening the Edge – Part 2 (LF Edge) (https://lfedge.org/wp-content/uploads/sites/24/2023/12/LFEdgeTaxonomyWhitepaper_062222.pdf)Software-as-a-Service (SaaS) overview (https://www.salesforce.com/saas/)Defining software deployment as days (https://dzone.com/articles/defining-day-2-operations)

Speaking like an edge native

In this section, you will learn to articulate fundamental differences between the edge and the cloud. This impacts the available infrastructure, platforms, services, and application deployments. Additionally, you will be able to explain concisely what the edge is and what the field of edge computing does to both line-of-business (LOB) executives and other non-IT professionals. This includes being able to explain the value it can provide, as well as why this field is emerging at this point in time.

What is the edge?

The edge in edge computing is commonly used to describe the location where computing takes place. The name itself is meant to evoke a spot in a corner or by the wayside, and not in a central area, and actually refers to the very end of a communications network (the edge of the internet; see Figure 1.1). Thus, edge computing happens outside a cloud computing facility, and many times outside the four walls of a traditional data center (DC).

Edge computing describes computing capabilities situated at degrees of distance from a centralized location, usually the cloud or a corporate DC. The placement of the equipment is chosen in order to improve the performance, security, and operating cost of the applications and services that will run in that environment. In exchange, some factors may be de-emphasized, such as resilience, availability, and throughput. Edge computing can reduce latency and bandwidth constraints of services by not transferring collected data to the cloud or a DC for processing and thus not needing to remotely retrieve subsequently generated information. Most recently, the edge has also become a frequent deployment target for control logic supporting industrial automation and machine learning (ML) models used in visual analytics tasks.

By shortening the distance between devices and the computational resources that serve them, the edge brings new value to existing use cases and can introduce new classes of applications. This results in distributing workloads and ML assets southbound along the path between today’s centralized DCs and the increasingly large number of deployed edge computing devices and clusters in the field, on both the service provider (SP) and user sides of the last mile network – the portion of the SP network that reaches user premises.

Note

When the terms “southbound” and “northbound” are used when discussing an application architecture, they refer to points of the compass in reference to the relative location of your current point of view. So, “northbound” would refer to services, tiers, and locations that are more physically proximate to the cloud, or, in the case of Figure 1.1, locations to the right-hand side. Likewise, “southbound” refers to locations closer to the user edge, or locations on the left-hand side.

Figure 1.1 – A representation of the edge as distinct from the cloud

Notice in the preceding diagram, which we will be using as a starting point for many charts used throughout the book, how all computing resources located to the left of the thick, black line labeled Internet Edge would be considered the edge, and all computing resources to the right of the line would be considered the cloud. Despite those designations, you might hear about “clouds” located in the SP edge referred to as “regional clouds” or “enterprise clouds” and in the user edge as “edge clouds.” Future iterations of the chart will collapse the Internet Edge and Last Mile Networks lines.

Edge computing, therefore, is described by ways in which its operating environments are different than the physical security, hardware homogeneity, and service scalability of cloud computing. Edge compute nodes (and by nodes, we include both standalone devices and compute clusters) can be solitary, and many times are not rack-mounted. Edge nodes may not have reliable or consistent power, network connectivity, or even air filtering, climate control, and controlled physical access. Multiplicities of edge nodes may not be the same version or brand of hardware, with differing specifications and capacities, and thus edge computing nodes are described as heterogeneous. Edge nodes may use smaller or fewer processors, slower and/or more power-efficient processors, and fewer specialty or co-processors to accelerate specific types of tasks or workloads. Last, edge nodes may have a permanent or fixed placement or might have mobility or otherwise be portable.

Moving on to the contents of edge nodes … the type of chip being used, the micro-architecture, could be mounted in a constrained device or an off-the-shelf, commodity unit, but it typically runs a Linux distribution or similar enterprise- or consumer-class operating system. We do not speak of embedded systems or fixed-function devices of the IoT class as being used for edge computing functions, although they certainly are used to send data northbound to edge computing systems.

Edge micro-architectures

Typical chip micro-architectures supported by most edge computing solutions include:

- x86_64 or amd64

- arm32 or arm6, arm7

- arm64 or armhf, including Apple M1 and M2

-ppc64le

-risc-v

- s390x (typically running LinuxONE)

When writing and packaging applications for the edge, we no longer write an application in a high-level language such as Python, NodeJS, or even Golang, and package it up for a package delivery system such as pip, npm, and others. Instead, we typically containerize the application to make it self-contained along with all its dependencies so that it doesn’t need to be installed. A container image is downloaded from a registry and run in a container engine such as Docker or Podman. There are also common techniques available to support multi-arch containers that will build and run on all the common micro-architectures listed previously, which is the approach we recommend using. See the following article for more information: https://developers.redhat.com/articles/2021/08/26/introduction-nodejs-reference-architecture-part-5-building-good-containers.

NOTE: Containers are not the only edge-native approach for isolating workloads. Enterprises may use virtual machines (VMs), serverless functions, or even WebAssembly (Wasm) depending on the code-base purpose, or execution environment. Regardless of the chosen approach, proper automation should be employed to ensure isolation is maintained.

Are the edge and the cloud extremes of the same thing?

In the previous paragraphs, we compared attributes of edge computing nodes largely by contrasting them with cloud computing hardware, connectivity, and facilities. Indeed, edge computing is largely distinguished from cloud computing by pointing out the differences and trade-offs, as depicted by the arrows at the bottom of the LF Edge diagram shown next:

Figure 1.2 – The edge continuum with trade-offs shown at the bottom with gray arrows

Image Source: Linux Foundation Whitepaper

Jeff Ready, former CEO of Scale Computing, has a pithy way of contrasting the edge with the cloud:

“The edge is really the inverse of the data center. A data center deployment is likely 1 or a small number of physical locations, hundreds of servers at those locations. The edge, on the other hand, is hundreds or thousands of locations, with often 1-3 servers at each one. You can’t manage them the same way. You’re still deploying thousands of servers, but with many, many locations you obviously can’t have a team of IT pros at each one like you would in a datacenter. You need automated deployment, automated management, automated error recovery to make the edge work.”

(https://blocksandfiles.com/2023/02/02/dell-vxrail-edge/)

Edge computing environments are very different from, and in most cases filling requirements that are the direct opposite of, cloud computing. As Eclipse’s Mike Milinkovich has said: “If you care about the physical location of your devices, then you are doing edge computing.” However, edge computing has been established on a foundation of software development processes informed by cloud-native development best practices. In short, edge computing would not be possible if it weren’t for the cloud.

How does edge computing bring value, and why now?

Edge computing reuses applicable cloud computing programming best practices, which give it a standard approach to software development that is fast, flexible, and works across multiple architectures. This methodology provides small teams with minimal cross-architecture experience in a way to create cross-platform distributed applications comprised of multiple loosely coupled services. This is what powers edge computing (and cheap computing).

Edge computing came about at a time when inexpensive but powerful compute became plentiful and custom fabrication tools more widely available. The Raspberry Pi single-board computer introduced ARM-based processors to hobbyists around the world at affordable prices while also spawning a large ecosystem of software utilities and hardware add-on boards. Since these systems could run many common Linux variants, they also formed the basis for proofs of concept (POCs) that could be easily turned into commercially viable solutions.

We’re now beginning to see a similar wave of innovation with RISC-V-based systems that will further enable low-powered and efficient solutions that could even be embedded into standard hardware components. This would bring us to a point where computers with a Linux operating system that are capable of running containerized workloads could be powering every household appliance and consumer device or component. For example, Intensivate is running containers on the RISC-V ISA-compatible SoC that controls SSD drives.

By virtue of having inexpensive but powerful compute available and placed adjacent to where data is being generated, and being able to program that compute using existing tools and methods, you can simultaneously reduce the cost of computation while decreasing response times and reducing latency. Complex analytics no longer require offloading to the cloud, but ultimately, the available trade-offs largely depend on which edge you choose for workload placement.

Which edge? Categorizing edges

In this section, we cover the names and characteristics of various edge categories (or edges) that are commonly used, including which terms have been deprecated or have fallen out of the vernacular. By the end, you should be able to list the edges and describe the benefits and drawbacks of each, as shown in exhaustive detail next (Figure 1.3):

Figure 1.3 – Detailed benefits and drawbacks of each edge

Image Source: Linux Foundation Whitepaper

The user edge – field-deployed compute

A fundamental confusion that commonly comes up in conversations revolves around where people think the edge is. One idea in people’s minds is that “the edge” may be in houses, commercial offices, factories, vehicles, and utility shacks on the side of the road or at the base of a cell tower. These types of locations are typically thought of as the far edge because they are farthest away from a DC or cloud on a network and typically beyond the last mile of an SP network – hence, they are at the edge of a network or the farthest possible location on the network from a peering point or exchange.

But, the far edge is not the only location where edge computing takes place. The Linux Foundation’s LF Edge organization refers to all edge computing locations falling after the last mile as belonging to the user edge, which follows a nomenclature categorizing types of computing by the owner of that compute. The fundamental assumption is that infrastructure at these locations is typically not shared beyond a single organization, business, or person. The Eclipse Foundation’s Edge Native Working Group terms it Field Deployed while seeing the last mile and its associated infrastructure collectively as Access-Transport, as shown in Figure 1.4:

Figure 1.4 – Eclipse Foundation Edge Native Working Group terms for edge

Image Source: Eclipse Foundation Whitepaper

The SP edge – regional compute

On the other side of that last mile network connection, but beyond the edge of the internet’s network infrastructure, is compute typically referred to as telco infrastructure belonging to communication SPs (CSPs). Satellite locations would be termed central offices (COs), and larger hubs would be regional offices (ROs). CSPs themselves are now comprised of phone companies (telcos and mobile operators or mobile virtual network operators (MVNOs)), content distribution networks (CDNs), and newer edge providers. They operate and offer programmable compute consisting of both software-enabled communications equipment and a limited amount of traditional racks of compute. LF Edge terms this collective category as the SP edge. The Edge Native Working Group calls this category simply regional and avoids associating it exclusively with SPs.

As the field of IoT computing was maturing, but before edge computing had gained widespread adoption, Cisco and others began using the term fog computing to refer to a method of distributing key cloud-like computing and storage infrastructure and services outside of the cloud and closer to devices. The term never entered widespread usage and was soon supplanted by the more general term edge computing to cover all computing outside of the cloud on programmable devices.

And lastly, you have traditional DCs. These are locations where physical access is controlled, racks of homogenous compute hardware are provided and remotely manageable, and both Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) are offered. These DCs are typically owned and used by a single party, but mostly only differ from the cloud or global compute by size and scale. Large DCs such as these are rarely referred to as locations where edge computing happens; however, they are technically part of the edge as long as they reside outside of the internet’s network.

Your computer or mine? Tactics for service deployment

In this section, we review different scenarios where more than one application or service can be deployed and running concurrently. We will give an example of each and discuss the purpose of that approach. By the end, you should recognize when each tactic is required.

Edge computing doesn’t require dedicated resources

In Sharpening the Edge, the author refers to edge computing as primarily using your own systems, while cloud computing involves sharing systems and infrastructure with others. This simplification is largely correct at the macro scale, although edge computing can also involve sharing: by running multiple applications on a single device at the same time for multiple users, or sequentially at regularly scheduled intervals (day versus night, weekdays versus weekends, business open versus business closed). In the case of CSP-hosted edge infrastructure, it could even include hosting applications from multiple tenants each in an isolated environment on shared edge devices or clusters like cloud providers would. Let’s take a deeper look at examples of each type of sharing in turn.

Single device, running multiple applications simultaneously

In a New England-based chip factory in late 2022, as reported by IBM in a blinded case study, IT staff deployed cameras containing a CPU and GPU capable of running Linux and containers. On those cameras, they placed containerized applications and ML models to detect if persons were wearing protective equipment, if the equipment was being worn properly, and if they maintained a safe distance from hazardous locations.

This involved multiple containers for object detection, object recognition, and object placement, as well as for sending messages and relevant screen captures extracted from video (with individual identities blurred out to preserve privacy) when infractions were detected above a specified level of certainty. The messages were sent over the local Wi-Fi network to an application on the shift manager’s mobile phone within seconds of detection whereby the receiving application alerted the manager to investigate further if the provided still image appeared to warrant it.

Before edge computing devices made this possible, a solution would have been built to stream video to the cloud where inferencing would have been performed. By the time the manager would have been informed, minutes would have passed, and the individuals would likely no longer be in the area. Edge computing removed the expense of transporting video feeds to the cloud, reduced the resulting inferencing latency, eliminated any cloud computing costs, and ultimately ensured that the manager was notified up to 3 or more minutes sooner.

Before the cloud, the factory would have sent closed-circuit television (CCTV) feeds to a monitoring location where one or more persons would have viewed a bank of screens looking for issues on low-resolution displays, and called a manager if they spotted any issues. This approach would have been even more expensive and slow, and thus only likely to have been used to prevent major losses or accidents, or recorded and reviewed by investigators at a later time to determine potential causes of an accident.

Single device, alternating applications by schedule or purpose

In a grocery store, low-resolution video cameras stream feeds to constrained edge nodes attached to cameras containing low-power CPUs and limited RAM. These compute devices can run limited inferencing in a single container using tiny ML models at a few frames per second.

With those capabilities, they are used during store hours for spill detection or traffic counting when pointed at an aisle, dwell time when pointed at an end cap, and shelf restocking when pointed at a row. After the store is closed, those applications are replaced by a security application that looks for the presence of persons when the location should be unoccupied.

Edge computing makes these capabilities possible at an operating cost of pennies per day and without needing more connectivity than a local network connection.

Hosted edge infrastructure – applications on shared compute

An edge SP that began by providing only network peering with internet backbones and cloud providers has now begun offering bare-metal servers with connectivity to one or more providers of customer choice and large amounts of low-cost bandwidth. They do not provide infrastructure or platform services, making their offering ideal for customers who need always-on, reliable, inexpensive connectivity while at the same time providing low latencies due to physical proximity to customer facilities.

Hosted edge nodes are ideal for supplementing customer edge workloads temporarily while also avoiding the vendor lock-in of proprietary cloud solutions. The drawback to using hosted nodes is that the customer will need to provide any infrastructure and platform services and support. But it makes for an excellent extension or overflow to existing customer DCs or for situations when a company outgrows its existing locations but has not yet secured new facilities.

It also works well for temporary events, especially when they take place in a specific or limited geographical area. To that end, there is even a start-up that will deliver a self-contained edge DC in a container to your location for as long as you need it.

Cloud-out versus edge-in

Another common way of describing an architecture is based on its foundation and assumptions, and in what direction and manner it grows as its scope and responsibilities increase. If it starts out based in the cloud, using cloud-native best practices, and then later adds on capabilities that allow it to run in some fashion on the edge, that approach is described as cloud-out. On the other hand, if it starts out on the edge using edge-native development best practices, and then bursts to (hybrid) cloud infrastructure, that would be termed edge-in. Let’s look at each in turn, go over an example, and discuss their relative strengths and weaknesses.

Looking deeper at cloud-out architectures

Cloud-out architectures begin with the cloud; that is, with global compute infrastructure using cloud-native development best practices. While Chapter 11 will discuss these practices in depth, let’s list an abbreviated version to frame the discussion:

Package independent, autonomous services in lightweight containers or other abstractionsDevelop in the most appropriate language and/or framework for the purposeCompose with loosely coupled microservicesProvide API-centric interfaces supporting common protocols and conventionsDeliver a clean separation of concerns (SoC), especially between stateless and stateful servicesAbstract from underlying dependencies, both hardware and operating systemDeploy on elastic infrastructure to automate scale-up and scale-outRely on independent, automated application lifecycle managementImplement configuration as code (CaC) maintained within an agile processDefine resource allocation through declarative policies

Source: https://thenewstack.io/cloud-native/10-key-attributes-of-cloud-native-applications/

Looking at the preceding summary, a good example of the cloud-out approach to application development would be building a product using the SaaS model. SaaS is a way of building and delivering software so that it does not need to be installed (it is hosted by someone, usually in the cloud), and it does not need to be purchased (it is paid by subscription). Access can be provided in a browser or over the internet via APIs.

SaaS solutions demonstrate the cloud-out approach because they are typically hosted in the cloud, implemented with microservices, abstracted from dependencies, and deployed on elastic infrastructure. Individual SaaS offerings may also follow many other cloud-native best practices, but compliance with those principles is not obvious without access to the source code.

SaaS solutions clearly do not demonstrate the edge-in approach because they are not typically built to handle dependency unavailability (hence built with highly available architectural principles), service portability, target system constraints (since they do not need to be installed or remotely deployed), and dependence on orchestration. Additionally, they presume an always-on network connection with low latency and high throughput.