SECURE AND CERTIFIABLE FUNCTIONS-AS-A-SERVICE

Abstract

Software and other electronic services are increasingly running in cloud computing environments. Edge computing environments can be used to bridge the gap between cloud computing environments and end-user software and electronic devices, and can implement Functions-as-a-Service (FaaS). FaaS can be used to create variants of specific services, a chain of related functions that implements all or part of a FaaS edge workflow or workload. A temporary software-defined wide-area network (SD-WAN) can be used to receive a computing request and split the request into multiple FaaS variants, enabling the dynamic creation of SD-WANs for each FaaS variant, executing the FaaS variants in their respective SD-WANs, returning a result, and then destroying the SD-WANs.The temporary FaaS SD-WAN extends to current edge systems by enabling the creation of low-latency virtual SD-WAN networks bound to a set of functional instances created to execute a specific service request.

Description

PRIOR ARTSoftware and other electronic services are increasingly executing in cloud computing environments (e.g., in the "cloud"). Edge computing environments (e.g., Internet of Things (IoT), Telco Edge, Enterprise Edge) may be used to close the gap between cloud computing environments and end user software and electronic devices, thereby achieving improved performance, lower bandwidth, and lower latency. Edge computing environments may implement Functions as a service (FaaS), which may provide serverless computing environments for individual application functions. Although FaaS provides service-based access to application functions, these remotely managed services may limit the adaptation of the application functionality. What is required is a FaaS environment that allows for improved adaptation of the application functionality.BRIEF DESCRIPTION OF THE DRAWINGSIn the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Like characters having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example and without limitation in the figures of the accompanying drawings, in which: FIG. 1 is a block diagram illustrating a FaaS frame according to an embodiment; FIG. 2 is a block diagram illustrating a FaaS chain distribution according to an embodiment; FIG. 3 is a block diagram illustrating a FaaS Temporary Software Defined Wide Area Network (FaaS Temporary SD-WAN), according to one embodiment; FIG. 4 is a block diagram illustrating the workflow of a tenant-enabled SD-WAN, according to an embodiment; FIG. 5 is a block diagram illustrating paging tenant security contexts according to an embodiment; FIG. 6 is a block diagram illustrating a demand-based FaaS variant chain paging according to an embodiment; FIG. 7 is a block diagram illustrating FaaS SD-WAN components according to an embodiment; FIG. 8 is a flow diagram illustrating a method for secure and attestable functions as a service, according to an embodiment;FIGS. 9A and 9B provide an overview of example components within a computing device in an edge computing system, according to an embodiment; FIG. 10 is a block diagram showing an overview of configuration for edge computing according to an embodiment; FIG. 11 illustrates operating layers between endpoints, an edge cloud, and cloud computing environments, according to an embodiment; FIG. 12 illustrates an example approach for networking and services in an edge computing system, according to an embodiment; FIG. 13 illustrates an example software distribution platform for distributing software, according to an embodiment; and FIG. 14 illustrates an example of an infrastructure processing unit (IPU) according to an embodiment.DETAILED DESCRIPTIONFaaS may be used to create variants of particular services, where FaaS variants are conceptually a chain (e.g., a directed graph) of related functions that implements all or part of a FaaS edge workflow or workload. In one example, a FaaS variant may be developed that focuses on monitoring based on system requirements (e.g., a series of images to be processed), customer requirements (e.g., request to identify threats within a second), and a series of resources in the edge computing platform (e.g., eight processor cores and a field programmable gate array (FPGA)). Serverless operation of FaaS and adaptation of FaaS varieties can improve the development, provisioning, and execution of applications, particularly in edge computing environments.In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some exemplary embodiments. However, those skilled in the art will appreciate that the present disclosure may be practiced without these specific details.FIG. 1 is a block diagram illustrating a FaaS frame 100, according to an embodiment. The FaaS framework 100 includes an edge platform 110 that may include a network interface card (NIC) 120 and a central processing unit (CPU) 130 for executing a FaaS-based service 140. The edge platform 110 may be used to bundle software files into a virtual container, e.g., a FaaS chain container 150. The FaaS chain container 150 may be used to perform multiple functions within the FaaS chain. Each FaaS within the FaaS chain container 150 may include one or more virtual containers for implementing and executing each FaaS.In operation of the FaaS frame 100, a computing request for a first service may be received at the edge platform 110 at a first time 115. At a second time 125, the edge platform 110 may create one or more virtual containers (e.g., FaaS chain containers 150), create the corresponding functions required to process the compute request, and connect the containers to process the compute request. At a third time 135, the edge platform 110 may perform the functions across the virtual containers. At a fourth time 145, the edge platform 110 may return the result of performing the functions and destroy the virtual containers (e.g., destroy FaaS chain containers 150) or remove confidential data for the requesting party. By destroying containers or purging sensitive data, the requesting party may be provided with better data protection or data integrity, particularly when various components within the edge platform 110 may be reused between data requests by other requesting parties. The execution of the FaaS chain container 150 within the edge platform 110 (e.g., within a single domain) may be used to provide further data security and function isolation, e.g., through the use of hardware virtualization functions such as intel virtualization technology for directed input / output (VT-d), intel software guard extensions (SGX), intel trust domain extensions (TDX), or other hardware virtualization functions.FIG. 2 is a block diagram illustrating a FaaS chain distribution 200 according to an embodiment. While the FaaS framework 100 may be used to execute a FaaS chain container 150 within a single edge domain, the FaaS chain distribution 200 may be used to execute a distributed FaaS chain 205 across multiple edge platforms. The distributed FaaS chain 205 may be initialized as a service on a first CPU within a first edge platform 210, and may distribute functions to other CPUs and other edge platforms (e.g., edge platform 220 and edge platform 230). Each FaaS within the distributed FaaS chain 205 may include one or more virtual containers for implementing and executing each FaaS. In the example of FIG. 2, the distributed FaaS chain 205 executes first and second FaaS on a first CPU on the first edge platform 210, executes third and fourth FaaS on a second CPU on the same first edge platform 210, executes fifth FaaS on a CPU on a second edge platform 220, and sixth and seventh FaaS on a CPU on the third edge platform 230. The functions may be distributed according to the capabilities of various edge platforms to execute one or more of the FaaS requests within the distributed FaaS chain 205. For example, the CPU on the second edge platform 220 may be particularly suitable for fast execution of the fifth FaaS.FIG. 3 is a block diagram illustrating a FaaS Temporary Software Defined Wide Area Network (FaaS Temporary SD-WAN) 300 according to an embodiment. The temporary FaaS SD WAN 300 may be used to receive a compute request and disassemble the compute request into multiple FaaS variants (e.g., a chain of related functions) that implement one or more FaaS, such as the FaaS shown in the temporary FaaS SD WAN container 305. The temporary FaaS SD WAN 300 may then enable the dynamic creation of SD WANs (e.g., virtual networks) for execution of one or more FaaS variants, execute the FaaS variants in their respective SD WAN, return a result, and optionally destroy the SD WANs. The temporary FaaS SD WAN 300 extends to current edge systems by enabling low latency virtual SD WAN networks to be created that are tied to a set of functional instances created to execute a particular service request.In the example shown in FIG. 3, the temporary FaaS SD WAN 300 may dynamically create a first SD WAN on a first CPU of a first edge platform 310, create a second SD WAN on a second CPU of the first edge platform 310, create a third SD WAN on a CPU on a second edge platform 320, and create a fourth SD WAN on a CPU on a third edge platform 330. Each SD-WAN may be associated with a series of services associated with a common instance of a particular service for a particular customer request, e.g., the various FaaS within the temporary FaaS SD-WAN container 305.In operation of the temporary FaaS SD WAN 300, a computing request for a first service may be received at the first edge platform 310 at the first time 315. At the second time 325, the first service on the first edge platform 310 may identify and create multiple FaaS to process the computing request, e.g., the FaaS variant chains shown in the FaaS SD WAN temporary container 305. At the third time 335, the edge platform infrastructure may create FaaS SD WANs in various switches and NICs on behalf of the service executing on the first edge platform 310, the second edge platform 320, and the third edge platform 330. In one example, the edge platform infrastructure includes a WAN controller to create and link edge platforms within a private WAN to provide the temporary distributed FaaS pipeline.At fourth time 345, each created SD WAN may be configured to enable connectivity across multiple services and initiate secure connections, e.g., secure connections between first edge platform 310, second edge platform 320, and third edge platform 330. Once the secure connections are established, at the fifth time 355, the sequence of FaaS requests (e.g., as indicated in the temporary FaaS SD-WAN container 305) may be processed over the entire chain of SD-WANs. After completion of the sequence of FaaS requests, the response to the compute request is generated at sixth time 365 and the virtual implementations of the functions and SD WANs are destroyed.For each SD WAN created by the temporary FaaS SD WAN 300, hardware acceleration may be used to improve the efficiency of creation and configuration of each SD WAN. In one example, hardware acceleration may be used to build and configure each SD WAN within microseconds (e.g., in less than ten microseconds). The temporary FaaS SD WAN 300 may also provide mechanisms by which each function (e.g., each FaaS) may recognize and confirm other established functions within a particular SD WAN, while at the same time providing isolation between any two SD WANs.Additional security may be used to provide improved protection of volatile data used in the temporary FaaS SD WAN container 305. For each FaaS variant, the FaaS variant may be examined to determine an appropriate cryptographic scheme, and each SD-WAN may be generated using this cryptographic scheme. This cryptographic management of FaaS variants may improve the ability of the temporary FaaS SD WAN 300 to configure SD WANs so that the output of each FaaS function is efficiently routed into the next FaaS function to achieve optimal performance.The temporary FaaS SD WAN 300 may provide further security enhancements by managing the attestation of each SD WAN. This improves the ability of the temporary FaaS SD WAN 300 to improve data security throughout the functional sequence. Each SD WAN may be defined based on a level of security, e.g., based on different classes (e.g., types) of workloads. For example, different classes of FaaS workloads may be associated with requirements or preferred operational levels for security, reliability, or fail-safe, and the temporary FaaS SD WAN 300 may implement each SD WAN based on these requirements or preferred operational levels. The temporary FaaS SD WAN 300 may use this security level to determine a corresponding certification level (e.g., relevant physical attributes of the host environments), and each SD WAN may be selected or configured to provide the corresponding certification level.The levels of attestation may be further defined or configured based on various requirements or requirements for the compute request, e.g., requirements or requirements listed in a Service Level Agreement (SLA) or Quality of Service (QoS) requirements associated with the compute request. To provide the appropriate assessment, the temporary FaaS SD WAN 300 may track the service capability for each SD WAN and change the resource allocation based on the tracked service capability. In one example, the temporary FaaS SD WAN 300 may detect degraded performance of an SD WAN and increase a switching bandwidth or switching priority in response to the detected degradation.FIG. 4 is a block diagram illustrating the workflow of a tenant-enabled SD-WAN 400, according to an embodiment. The tenant-enabled SD-WAN 400 workflow may include a tenant-enabled SD-WAN 405 that may be used for processing computing requests for multiple tenants. In one example, a first computational request of tenant A 410 may be implemented in variant A chain 420, and a separate computational request of tenant B 415 may be implemented in variant B chain 425. Each variant chain may have multiple containerized functions (e.g., multiple FaaS), and the connections between the individual function pairs (e.g., the input and output data between the function pairs) may be protected by a security context. In one example, variant A chain 420 includes security context A1 430 between the first and second containerized functions and security context A2 440 between the second and third functions. Similarly, variant B chain 425 includes security context B1 435 between its first and second functions and security context B2 445 between its second and third functions.In various examples, each security context may include data encryption keys, symmetric or asymmetric identity keys, attestation keys, and attestation policies for checking a next node in the FaaS chain. The keys used in the individual security contexts may be derived using an attestable trust anchor, e.g., a DICE (Device Identity Composition Engine), a DPE (DICE Protection Environment), a calliptra open source trust anchor, a TPM (Trusted Platform Module), or another attestable trust anchor technology.To ensure improved performance during execution of each variant chain, the security contexts for each variant chain may be precomputed. Pre-computation of each security context may reduce latency or reduce the computational resources used in generating each SD-WAN, and may reduce execution jitter (e.g., variations in delay in executing the individual FaaS) during execution of the variant chain. This improves the ability to dynamically create an authenticated security context for each FaaS variant used by a particular SD-WAN.The tenanted SD-WAN 405 may enable rapid initialization or destruction (e.g., decomposition) of one or more variant chains. For example, when the tenant-enabled SD WAN 405 is decomposed, this may result in the decomposition of both the variant A chain 420 and the variant B chain 425. In another example, the tenant-enabled SD WAN 405 may be configured such that either variant A chain 420 or variant B chain 425 may be decomposed without decomposing the other variant chain.The decomposition of a variant chain can typically result in the associated security contexts being decomposed. In cases where a tenant frequently subscribes to workloads that include the same FaaS functions or variants, the decomposition operations may not be completed. A tenant-specific security context may be encrypted (e.g., enclosed) by a storage key (e.g., tenant-specific storage key, SLA-specific storage key, etc.). The storage key may be discarded by the host environment after completion of execution, and the storage key may be re-acknowledged by the tenant when the tenant requests the FaaS variant chain the next time. In one example, after completion of variant A chain 420, tenant-enabled SD WAN 405 may release memory associated with security context A 1 430 and security context A 2 440, and tenant A 410 may subsequently request execution of variant A chain 420 and re-confirm both security context A 1 430 and security context A 2 440. The security key can be re-confirmed after disassembly of a variant chain or after expiration of a predetermined time between the subsequent executions of a variant chain. Upon re-authentication of a security key, the tenant-enabled SD-WAN 405 may retrieve a storage key from a secure storage paging architecture, e.g., the security contexts of the paging tenant shown in FIG. 5.FIG. 5 is a block diagram illustrating the security contexts of the paging tenant 500 according to an embodiment. Tenant security contexts 500 provide a replacement of security contexts between SD WAN 510 and hard disk storage as cache 520. Tenant security contexts 500 may be used to provide paging (e.g., retrieval of preconfigured data or processes) tenant security contexts from the hard disk storage as cache 520 into one or more FaaS variant chains within SD WAN 510. The SD WAN 510 and hard disk storage as cache 520 may be used for creating and paging client-specific security contexts of FaaS variant chains based on demand. After executing a FaaS variant chain, paging the security context may include encrypting a security context with a storage key, discarding the storage key, and swapping the encrypted security context into the hard disk storage as cache 520. In an example shown in FIG. 5, after completion of the FaaS function A2 545, the security context A11 540 is swapped out to the hard disk memory as cache 520. Subsequently, when a FaaS variant chain is acknowledged, the security context paging may include paging in the encrypted security context from the hard disk storage as cache 520, re-confirming the storage key, and decrypting the security context by the storage key. In the example shown in FIG. 5, during a subsequent acknowledgement of the FaaS variant A chain, the security context A 11 540 is read into FaaS FNA 1 535.The hard disk storage as cache 520 may be implemented in a centralized storage scheme (e.g., a single logical or physical storage device) or in a distributed storage scheme (e.g., across multiple logical or physical storage devices). The hard disk storage as cache 520 may include non-volatile memory, such as intel Optane memory, 3D XPoint NVM (non-volatile memory), NOT-AND (NAND) flash memory, solid state drive (SSD) memory, self-encrypting drive (SED) memory, hard disk (HDD) memory, magnetic disk storage, magnetic tape storage, and other types of non-volatile memory. The hard disk storage as cache 520 may be partitioned into security zones to create virtual barriers for security isolation between tenants, variants, or security contexts, such as use of trusted computing group (TCG) Opal storage specification for SED memories, an IEEE1393 security overlay, or other virtual SSD or SED barriers.In one example, the security context A 11 540 may match the previously used image of security context A 1 530. In another example, after paging, the security context A 11 540 may be updated to be different from the previously used image of the security context A 1 530. Updates to the security context may be applied as part of the key management activities for various security purposes, e.g., to provide or re-provide security keys, security tickets, security tokens, security certificates, or other security credential. A software or firmware update may trigger a change in the attestation keys when the attestation keys are derived from the DICE layering, e.g., when a firmware initializes (e.g., seeds) a repeatable key generation function. A configuration change may also function as a key management event that may result in updated attestation keys, updated attestation credentials, or updated security contexts, for example, to reflect security level adjustments due to configuration changes. Policies for tenants or FaaS variants may be used to determine parameters of acceptable configurations that may trigger an update of a tenant security context in response to a firmware update or other configuration changes.The updates to the security context may be applied by a Flavor Management Service (FMS) or similar security administration entity. The FMS may use a memory partitioning scheme that uses storage class encryption to protect security credential from, for example, physical attackers who may restore the paging or caching device and subject it to a variety of brute force attacks. The FMS may manage SED keys and partitions according to tenant defined isolation requirements or according to an associated SLA.FIG. 6 is a block diagram illustrating a demand-based FaaS variant chain paging 600 according to an embodiment. Compared to tenant security context 500 that offers a replacement of security contexts, tenant-specific demand-based FaaS variant chain paging 600 provides tenant-specific FaaS variant replacement between SD-WAN 610 and hard disk storage as cache 620. The demand-based paging 600 of the FaaS variant chain may be used to provide the paging of a FaaS variant chain specific to tenant A 615. Each FaaS variant chain that is read or swapped in may include functions, data, and security contexts required to execute that FaaS variant chain. In one example, a FaaS request from tenant A 615 may determine which FaaS variant chain to read, such as identifying variant A chain 640 from tenant A. In another example, a variant chain is swapped out after execution of a variant chain and then read in at the next request to execute that variant chain. In an example shown in FIG. 6, after execution of the FaaS variant A chain, variant A1 chain 630 of tenant A is swapped from the SD WAN 610 to the hard disk storage as cache 620, and at the next request to execute the variant A chain, variant A chain 640 of tenant A is swapped from the hard disk storage as cache 620 to the SD WAN 610.FIG. 7 is a block diagram illustrating FaaS SD WAN components 700 according to an embodiment. The FaaS SD-WAN components 700 include a FaaS SD-WAN architecture 710 that includes various components that may be used to implement or secure a temporary FaaS SD-WAN. Each of the components within the FaaS SD WAN architecture 710 may be implemented as a logic programming module (e.g., application programming interface (API)), a special purpose physical circuit (e.g., on an application specific integrated circuit (ASIC), on a system on a chip (SOC)), or in a combination of physical and logic components.The FaaS SD-WAN architecture 710 may include a FaaS SD-WAN life cycle management component 720. The FaaS SD WAN lifecycle management component 720 may provide interfaces to various services to, e.g., create an instance of a particular service with particular service requirements (e.g., security, data preservation). The FaaS SD-WAN lifecycle management component 720 may interact with other components within the FaaS SD-WAN architecture 710 to identify the edge nodes on which to establish the functions of creating the FaaS SD-WAN temporary container 725 and tracking the performance of the FaaS SD-WAN temporary container 725 (e.g., monitoring network quality (QoS) and deleting the FaaS SD-WAN temporary container 725 after completion of the service).The FaaS SD-WAN architecture 710 may include a FaaS SD-WAN network management component 730. The FaaS SD-WAN network management component 730 may be used to create the FaaS SD-WAN temporary container 725 based on a computing service request. A computing service request may include requests or requests for various FaaS variant instances, and the FaaS SD WAN network management component 730 may configure one or more edge computing network components 735 (e.g., router, switch, NIC). In various examples, the configuration of computing network components 735 may include the configuration of the requested or required security levels, QoS levels, computing power levels, data isolation, or other requests or requests for that FaaS variant instance.The FaaS SD WAN architecture 710 may include a security context management component 740. The security context management component 740 may be used to manage security contexts for each FaaS variant chain. This management of security contexts may include security contexts for caching and retrieving from the hard disk storage, wherein security contexts may be specific to a tenant or specific to a FaaS variant chain. The security context management component 740 may apply updates to the security context as part of key management activities for various security purposes, e.g., to provide or re-provide various security credential information.The FaaS SD WAN architecture 710 may include an attach logic component 750. The attestation logic component 750 may provide attestation interfaces for requested computer services that may be used to validate and authenticate content of other services. The attestation logic component 750 may interact with the security context management component 740 to provide these attestation interfaces.The FaaS SD WAN architecture 710 may include a paging and caching logic component 760. The paging and caching logic component 760 may cache the reading into and unloading of security contexts or FaaS variants from the hard disk memory. The paging and caching logic component 760 may manage hard disk storage as a cache implemented in either a centralized storage scheme or a distributed storage scheme.The components within the FaaS SD WAN architecture 710 may be implemented in various combinations of computer components or instructions. In various examples, the components of the FaaS SD-WAN architecture 710 may be implemented in an integrated circuit (e.g., hard-coded circuit), firmware, dedicated hardware circuits (e.g., field programmable gate array (FPGA)), application specific integrated circuit (ASIC), system on a chip (SOC)), or similar electronic component.FIG. 8 is a flow diagram illustrating a method 800 for secure and attestable functions as a service. Method 800 includes receiving 810 a first service execution request on a first edge computing device, wherein the first edge computing device includes a first processor device and a first memory. Method 800 also includes identifying 820, based on the first service execution request, a first function as a service and a second function as a service. Method 800 further includes sending 830 first function instructions to a second processor device on a second edge computing device to execute the first function as a service and return a first function response. Method 800 may further include sending 840 second function instructions to a third processor device on a third edge computing device to execute the second function as a service and provide a second function response. Method 800 may further include returning 850 a service request result of the first service execution request based on the first function response and the second function response.Method 800 may further include identifying 860, based on the first service execution request, a third function as a service. Method 800 may further include executing 870 the third function as a service at the first processor device at the first edge computing device and returning a third function response. The result of the service request may be based on the third function response. Method 800 may further include generating 880 a first software-defined network at the first processor device based on the first service execution request. The first function as a service may be executed on the first software defined network.The first or second processor device may be attacked as part of a binding of an execution resource as part of a SW defined network. The function to be executed may be evaluated according to a security context, wherein the evaluation determines whether the protection characteristics of the first or second processor device are sufficient to protect the workload to be executed. The execution of the first function as a service at the first processor device or the execution of the second function as a service at the second processor device may take place in response to a result of an assessment of the security context.In response to the first service execution request, a function as a service variant chain may be read from a first volume cache as memory. The first software-defined network and the second software-defined network may be generated based on the service variant chain.In response to the first completion of the first function as a service, the first software defined network may be destroyed. In response to a second completion of the second function as a service, the second software defined network may be destroyed.Upon completion of the first service execution request, a second compute request may be received. The second computing request may include a request to execute the first function as a service and the second function as a service. It may be determined that a period of time for security assessment has elapsed since completion of the first service execution request. In response to the determination, a first security of the first software-defined network and a second security of the second software-defined network may be attacked. In response to the first security of the first software-defined network being tested, the first function may be executed as a service (function-as-a-service). Similarly, in response to the second security of the second software-defined network being tested, instructions may be sent to the second processor device to execute the second function as a service (function-as-a-service).A third function as a service may be identified based on the first service execution request. In response to the identification, instructions may be sent to a third processor device on the first edge computing device to execute the third function as a service.The first function as a service may generate a first intermediate result that executes on the first edge computing device. The second function as a service may generate a second intermediate result based on the first intermediate result. The result of the service request may be generated based on the second intermediate result.A first security context can be read in at the first processor device. A first secure network connection may be created between the first edge computing device and the second edge computing device. The first intermediate result may be transmitted over the first secure network connection. In one example, a security assessment for the first intermediate result may be sent with the first intermediate result over the first secure network connection.A first security context may be swapped out by the second edge computing device after the first intermediate result is sent over the first secure network connection. The first security context may be swapped out from the second edge computing device to the second hard disk cache as memory. In a subsequent execution of the function as a service, a second security context may be transferred from a second hard disk cache as a storage device to the first edge computing device. A result of the security assessment of a first edge computing device may be compared to a stored assessment result (e.g., expected assessment result). The comparison may include a change in the attestation status occurring during execution and whether the read security context includes the appropriate protection actions before proceeding to the second stage of FaaS chain processing.The first edge computing device may be in networked communication with a second edge computing device. The first edge computing device may be located at a first location and the second edge computing device may be located at a second location, the second location different from the first location. The first processor device may include at least one logical processor device and a physical processor device.FIGS. 9A and 9B provide an overview of example components within a computing device in an edge computing system 900, according to one embodiment. Edge computing system 900 may be used to provide secure and attestable functions as a service, e.g., method 800 and related systems and methods described above with respect to FIGS. 1-8.In further examples, any of the compute nodes or devices discussed with reference to the present edge computing systems and environment may be satisfied based on the components shown in FIGS. 9A and 9B. Respective edge computing nodes may be implemented as a type of device, device, computer, or other "ping" capable / s of communicating with other edge, network, or endpoint components. For example, an edge computing device may be embodied as a personal computer, server, smartphone, mobile computing device, smart device, in-vehicle computing system (e.g., navigation system), stand-alone device having an outer housing, a shroud, etc., or one(s) other device(s) or system capable of performing the described functions.In the simplified example illustrated in FIG. 9A, an edge computing node 900 includes a compute engine (also referred to herein as "compute circuitry") 902, an input / output subsystem 908 (also referred to herein as "I / O circuitry"), a data storage 910 (also referred to herein as "data storage circuitry"), a communication circuitry subsystem 912, and optionally one or more peripheral devices 914 (also referred to herein as "peripheral device circuitry"). In other examples, respective computing devices may include other or additional components, such as those commonly found in a computer (e.g., a display, peripheral devices, etc.). Additionally, in some examples, one or more of the illustrative components may be integrated with or otherwise form a part of another component.The compute node 900 may be implemented as any type of engine, device, or collection of devices capable of performing various computing functions. In some examples, the compute node 900 may be implemented as a single device, such as an integrated circuit, embedded system, field programmable gate array (FPGA), system on a chip (SOC), or other integrated system or device. In the illustrative example, the compute node 900 includes or is embodied as a processor 904 (also referred to herein as "processor circuitry") and a memory 906 (also referred to herein as "memory circuitry"). The processor 904 may be implemented as any type of processor capable of performing the functions described herein (e.g., executing an application). The processor 904 may be implemented, for example, as one or more multi-core processors, a microcontroller, a processing unit, a specialized or special purpose processing unit, or another processor or processing / control circuit.In some examples, processor 904 may be implemented as, include, or coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other specialized hardware to enable performance of the functions described herein. In some examples, processor 904 may be implemented as a specialized x-processing unit (xPU), also known as a computing device (DPU), an infrastructure processing unit (IPU), or a network processing unit (NPU). Such an xPU may be implemented as a stand-alone circuit or circuit package, integrated within an SOC, or integrated with networking circuitry (e.g., in smart NIC or enhanced smart NIC), acceleration circuitry, storage devices, storage disks, or AI hardware (e.g., GPUs, programmed FPGAs, or ASICs customized to implement an AI model such as a neural network). Such an xPU may be configured to receive, retrieve, and / or otherwise obtain programming to process one or more data streams and perform specific tasks and actions for the data streams (such as hosting microservices, performing service management or orchestration, organizing or managing server or datacenter hardware, managing service networks, or collecting and distributing telemetry) external to the CPU or universal processing hardware. However, it should be appreciated that an xPU, SOC, CPU, and other variations of processor 904 may operate in coordination with one another to perform many types of operations and instructions within and on behalf of computing node 900.Memory 906 may be embodied as any type of volatile memory (e.g., dynamic random access memory (DRAM), etc.) or non-volatile memory or data storage that can perform the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of data stored by the medium. Examples of volatile memories may be various kinds of RAM (random access memory), such as DRAM or SRAM (static random access memory). One particular type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM).In one example, the memory device (e.g., memory circuitry) is any number of block addressable memory devices, such as those based on NAND or NOR technologies (e.g., single-level cell ("SLC"), multi-level cell ("MLC"), quad-level cell ("QLC"), tri-level cell ("TLC"), or any other NAND). In some examples, the memory device(s) includes / include a byte addressable three-dimensional fixed write cross-point memory device or other byte addressable non-volatile memory (NVM) devices such as single or multilevel phase change memory (PCM) or phase change memory with a switch (PCMS), NVM devices using chalcogenide phase change material (e.g., chalcogenide glass), resistive metal oxide-based, oxygen vacancy-based, and conductive bridge random access memory (CB-RAM), nanowire memory, ferroelectric transistor random access memory (FeRAM), magnetoresistive random access memory (MRAM) including memristor technology, Spin Transfer Torque (STT) MRAM, a spintronic magnetic junction memory-based device, a magnetic tunnel junction (MTJ)-based device, a domain wall (DW) and spin orbit transfer (SOT)-based device, a thyristor-based memory device, a combination of any of the above, or other suitable memory. A memory device may also include a three-dimensional cross point memory device (e.g., Intel® 3D XPointTM memory) or other byte addressable non-volatile storage devices for fixed writing. The memory device may refer to the die itself and / or to an encapsulated memory product. In some examples, the 3D crosspoint memory (e.g., Intel® 3D XPoint™ memory) may include a transistorless stackable crosspoint architecture in which memory cells sit at the intersection of word lines and bit lines and are individually addressable and in which bit storage is based on a change in volume resistance. In some examples, all or a portion of memory 906 may be integrated with processor 904. The memory 906 may store various software and data used during operation, such as one or more applications, data operated on by the application(s), libraries, and drivers.In some examples, resistor-based and / or transistorless memory architectures include nanometer-scale phase-change memory (PCM) devices in which a volume of phase-change material is located between at least two electrodes. Portions of the exemplary phase change material exhibit varying degrees of crystalline phases and amorphous phases, wherein varying degrees of resistance between the at least two electrodes may be measured. In some examples, the phase change material is a chalcogenide-based glass. Such resistive memory devices are sometimes referred to as memristive devices that resemble the history of the current that has previously passed through them. Stored data is retrieved from example PCM devices by measuring the electrical resistance, where the crystalline phases have one or more relatively lower resistance values (e.g., logic "0") compared to the amorphous phases having one or more relatively higher resistance values (e.g., logic "1").Exemplary PCM devices store data over long periods of time (e.g., about 10 years at room temperature). Write operations to example PCM devices (e.g., set to logic "0", set to logic "1", set to an intermediate resistance) are achieved by applying one or more current pulses to at least two electrodes, the pulses having a particular current magnitude and duration. For example, a long low current pulse (SET) applied to the at least two electrodes may cause the example PCM device to be in a low resistance crystalline state, while a comparatively short high current pulse (RESET) applied to the at least two electrodes may cause the example PCM device to be in a high resistance amorphous state.In some examples, the implementation of PCM devices enables computing architectures that are not Neumann-type and enable intra-memory computing capabilities. Generally speaking, traditional computing architectures include a central processing unit (CPU) communicatively coupled to one or more memory devices via a bus. As such, a finite amount of energy and time is consumed to transfer data between the CPU and memory, which is a well known bottleneck of von Neumann computing architectures. However, PCM devices minimize and eliminate data transfers between the CPU and the memory in some cases by performing some computational operations within the memory. In other words, PCM devices not only store information but also perform computing tasks. Such non-Neumann type computational architectures may implement vectors with relatively high dimensionality to facilitate hyperdimensional computing, such as 10,000 bit vectors. Vectors with relatively large bit widths allow computational paradigms modeled after the human brain, which also processes information analogous to wide bit vectors.The computing circuitry 902 is communicatively coupled to other components of the computing node 900 via the I / O subsystem 908, which may be implemented as circuitry and / or components to enable input / output operations with the computing circuitry 902 (e.g., with the processor 904 and / or the main memory 906) and other components of the computing circuitry 902. I / O subsystem 908 may be embodied as, or otherwise include, for example, memory controller hubs, input / output controller hubs, integrated sensor hubs, firmware devices, communication links (e.g., point-to-point links, bus connections, wires, cables, light pipes, printed circuit board traces, etc.), and / or other components and subsystems to enable the input / output operations. In some examples, the I / O subsystem 908 may form part of a system on a chip (SoC) and be integrated with the computing circuitry 902 along with the processor 904 and / or the memory 906 and / or other components of the computing circuitry 902.The one or more illustrative data storage devices / storage disks 910 may be embodied as one or more of any types of physical devices configured for short-term or long-term storage of data, such as storage devices, memories, circuitry, memory cards, flash memories, hard disk drives, solid state drives (SSDs), and / or other data storage devices / disks. Individual data storage devices / disks 910 may include a system partition that stores data and firmware code for the data storage device / disk 910. Individual data storage devices / disks 910 may also include one or more operating system partitions that store data files and executables for operating systems depending on, for example, the type of computing node 900.Communication circuitry 912 may be implemented as any communication circuit, device, or collection thereof capable of enabling communications over a network between computing circuitry 902 and another computing device (e.g., an edge gateway of an implementing edge computing system). Communication circuitry 912 may be configured to implement such communication, one or more of any communication techniques (e.g., wired or wireless communications) and associated protocols (e.g., a cell-based networking protocol such as a 3GPP-4G or 5G standard, a wireless local area network protocol such as IEEE 1102.11 / Wi-Fi® a wireless wide area network protocol, Ethernet, Bluetooth® Bluetooth Low Energy, an IoT protocol such as IEEE 1102.15.4 or ZigBee® low power wide area network, LPWAN, or LPWA protocols, etc.).The illustrative communication circuitry 912 includes a network interface controller (NIC) 920, which may also be referred to as a host fabric interface (HFI). The NIC 920 may be embodied as one or more add-on boards, sub-cards, network interface cards, control chips, chipsets, or other devices that may be used by the compute node 900 to connect to another compute device (e.g., an edge gateway node). In some examples, the NIC 920 may be implemented as part of a system on a chip (SoC) that includes one or more processors, or included on a multichip package that also includes one or more processors. In some examples, the NIC 920 may include a local processor (not shown) and / or local memory (not shown), both of which are local to the NIC 920. In such examples, the local processor of the NIC 920 may be capable of performing one or more of the functions of the computing circuitry 902 described herein. Additionally or alternatively, in such examples, the local memory of the NIC 920 may be incorporated into one or more components of the board-level, socket-level, chip-level, and / or other level client computing node.Additionally, in some examples, a respective compute node 900 may include one or more peripheral devices 914. Such peripheral devices 914 may include any type of peripheral device found in a computing device or server, depending on the particular type of computing node 900, such as audio input devices, a display, other input / output devices, interface devices, and / or other peripheral devices. In further examples, compute node 900 may be implemented by a respective edge computing node (whether a client, gateway, or aggregation node) in an edge computing system or similar forms of devices, computers, subsystems, circuitry, or other components.In a more detailed example, FIG. 9B illustrates a block diagram of an example of components that may be present in an edge computing node 950 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described herein. This edge computing node 950 provides a closer view of the respective components of the node 900 when implemented as a computing device (e.g., a mobile device, a base station, a server, a gateway, etc.) or as part of such. The edge computing node 950 may include any combination of the hardware or logic components recited herein, and may include or be coupled to any device usable with an edge communication network or combination of such networks. The components may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or a combination thereof, adapted in edge computing node 950, or as components otherwise integrated into a package of a larger system.The edge computing device 950 may include processing circuitry in the form of a processor 952, which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, an xPU / DPU / IPU / NPU, a special purpose processing unit, a specialized processing unit, or other known processing elements. The processor 952 may be part of a system-on-a-chip (SoC) in which the processor 952 and other components are formed in a single integrated circuit or package, such as the Edison™ or Galileo™ SoC boards from Intel Corporation, Santa Clara, California, USA. As an example, processor 952 may include a Intel® architecture Core™ based CPU processor, such as a Quark™ class, Atom™ class, i3, class, i5, class, i7, class 9, or class MCU processor, or other such processor available from Intel®. However, any number of other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD®) of Sunnyvale, California, a MIPS® based design of MIPS Technologies, Inc. of Sunnyvale, California, a ARM® based design licensed by ARM Holdings, Ltd. or a customer thereof, or their licensees or users. The processors may include units such as an A5-A13 processor from Apple® Inc., an Snapdragon™ processor from Qualkomm® Technologies, Inc., or an OMAP™ processor from Texas Instruments, Inc. The processor 952 and the accompanying circuitry may be provided in a single socket form factor, a multi-socket form factor, or a variety of other formats, including in limited hardware configurations or configurations that include less than all of the elements shown in FIG. 9B.Processor 952 may communicate with system memory 954 via an interconnect 956 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. As examples, the memory 954 may be random access memory (RAM) according to a joint electron device engineering council (JEDEC) design, such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In certain examples, a memory component may comply with a DRAM standard promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4. Such standards (and similar standards) may be referred to as DDR-based standards, and communication interfaces of the storage devices implementing such standards may be referred to as DDR-based interfaces. In various implementations, the individual memory devices may be any number of different package types, such as a single die package (SDP), dual die package (DDP), or quad die package (Q17P). These devices may be soldered directly to a motherboard in some examples to provide a lower profile solution, while in other examples the devices are configured as one or more memory modules that in turn couple to the motherboard through a particular connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of various variants including, but not limited to, microDIMMs or MiniDIMMs.To provide persistent storage of information such as data, applications, operating systems, and so forth, storage 958 may also be coupled to processor 952 via interconnect 956. In an example, storage 958 may be implemented via a solid state disk drive (SSDD). Other devices that may be used for storage 958 include flash memory cards, such as secure digital, SD, cards, microSD, eXtreme digital, XD, video cards, and the like, and universal serial bus, USB, flash drives. In one example, the memory device may be or may include memory devices including chalcogenide glass, NAND flash memory with multiple threshold levels, NOR flash memory, single or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM), memory including memristor technology, resistive memory including metal oxide based, oxygen vacancy based, and conductive bridge random access memory (CB-RAM), or spin transfer torque MRAM (STT), a spintronic magnetic junction based device, The devices may be of the magnetic tunnel junction (MTJ) type, a domain wall (DW) and spin orbit transfer (SOT) type, a thyristor-based memory device, or a combination of any of the above or other memories.In low power implementations, the storage 958 may be on-chip memory or registers associated with the processor 952. However, in some examples, storage 958 may be implemented using a micro-hard disk drive (HDD). Further, any number of new technologies for storage 958 may be used in addition to, or in place of, the described technologies, such as, but not limited to, AC resistor memories, phase change memories, holographic memories, or chemical memories.The components may communicate via the interconnect 956. The interconnect 956 may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The interconnect 956 may be a proprietary bus used in, for example, a SoC-based system. Other bus systems may be included, such as, but not limited to, an I2C interface, a serial peripheral interface, SPI interface, point-to-point interfaces, and a power bus.The interconnect 956 may couple the processor 952 to a transceiver 966 for communication with the connected edge devices 962. The transceiver 966 may use any number of frequencies and protocols, such as, but not limited to, transmissions at 2.4 gigahertz (GHz) under the IEEE 1102.15.4 standard using the Bluetooth® low energy standard (BLE) as defined by the Bluetooth® Special Interest Group or the ZigBee® standard. Any number of radios configured for a particular wireless communication protocol may be used for connections to the connected edge devices 962. For example, a wireless local area network, WLAN, unit may be used to implement Wi-Fi® communications in accordance with the 1102.11 Institute of Electrical and Electronic Engineers (IEEE) standard. Additionally, wireless wide area communications, e.g., in accordance with a cellular or other wireless wide area protocol, take place over a wireless wide area, WWAN, unit.The wireless network transceiver 966 (or multiple transceivers) may communicate using multiple standards or radios for communications within a different range. For example, edge computing node 950 may communicate with nearby devices, e.g., within about 10 meters using a local transceiver based on Bluetooth Low Energy (BLE) or other low power radio to conserve power. More remote connected edge devices 962, e.g., within about 50 meters, may be reached via ZigBee® or other intermediate power radios. Both communication techniques may take place over a single radio at different power levels or take place over separate transceivers, for example a local transceiver using BLE and a separate mesh transceiver using ZigBee®.A wireless network transceiver 966 (e.g., a radio transceiver) may be included to communicate with devices or services in a cloud (e.g., an edge cloud 995) via local or wide area network protocols. The wireless network transceiver 966 may be a low power, wide area, LPWA, transceiver that complies with, among other things, the IEEE 1102.15.4 or IEEE 1102.15.4g standards. The edge computing node 950 can communicate over a wide range using LoRaWAN™ (long range wide area network) developed by Semtech and LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers implementing long-range, low-bandwidth communications, such as Sigfox and other technologies. Further, other communication techniques such as channel hopping with time slots described in the specification IEEE 1102.15.4e may be used.Any number of other radio communications and protocols may be used in addition to the systems mentioned for the wireless network transceiver 966 described herein. The transceiver 966 may include, for example, a cell-based transceiver that uses spread spectrum (SPA / SAS) communications to implement high speed communications. Further, any number of other protocols may be used, such as Wi-Fi® networks for medium speed communications and provision of network communications. The transceiver 966 may include radios compatible with any number of third generation partnership project (3GPP) specifications, such as long term evolution (LTE) and fifth generation (5G) communication systems, which are discussed in more detail at the end of the present disclosure. A network interface controller (NIC) 968 may be included to provide wired communication to nodes of the edge cloud 995 or to other devices, such as the attached edge devices 962 (e.g., operating in a mesh network). The wired communication may provide an Ethernet connection or may be based on other types of networks, such as controller area network (CAN), local interconnect network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among many others. An additional NIC 968 may be included to enable connection to a second network, for example, a first NIC 968 providing communications with the cloud over Ethernet and a second NIC 968 providing communications with other devices over a different type of network.Given the variety of types of applicable communications from the device to another component or network, applicable communication circuitry used by the device may include or be formed by any one or more of components 964, 966, 968 or 970. Accordingly, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be configured by such communication circuitry.The edge computing node 950 may include or be coupled to acceleration circuitry 964 executed by one or more artificial intelligence (AI) accelerators, a neural computing stick, neuromorphic hardware, an FPGA, an array of GPUs, an array of xPUs / DPUs / IPU / NPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuitry configured to perform one or more specialized tasks. These tasks may include AI processing (including operations for machine learning, training, inference, and classification), visual data processing, network data processing, object detection, rule analysis, or the like. These tasks may also include the specific edge computing tasks for service management and service operations discussed elsewhere herein.The interconnect 956 may couple the processor 952 to a sensor hub or external interface 970 used to connect additional devices or subsystems. The devices may include sensors 972 such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, global navigation system (e.g., GPS) sensors, pressure sensors, barometric pressure sensors, and the like. The hub or interface 970 may be further used to connect the edge computing node 950 to actuators 974 such as circuit breakers, valve actuators, an acoustic sound generator, a visual warning device, and the like.In some optional examples, various input / output or I / O devices may be present within or connected to edge computing node 950. For example, a display or other output device 984 may be included to display information such as sensor readings or actuator position. An input device 986, such as a touch screen or keypad, may be included to accept input. An output device 984 may include any number of forms of audio or visual display, including simple visual outputs such as binary status indicators (e.g., light emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs such as display screens (e.g., liquid crystal display (LCD) screens), wherein the output of characters, graphics, multimedia objects, and the like is generated or produced from the operation of the edge computing node 950. Display or console hardware may be used in the context of the present system to provide output and receive input of an edge computing system; manage components or services of an edge computing system; identify a state of an edge computing component or service; or perform any other number of management or administration functions or service application instances.A battery 976 may provide power to the edge computing node 950, although in examples where the edge computing node 950 is mounted in a fixed location, it may include a power supply coupled to a power grid, or the battery may be used as failsafe or temporary functions. The battery 976 may be a lithium ion battery or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.A battery monitoring / charging device 978 may be included in the edge computing node 950 to track the state of charge (SoCh) of the battery 976 if included. The battery monitoring / charging device 978 may be used to monitor other parameters of the battery 976 to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery 976. The battery monitoring / charging device 978 may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix, Arizona, or an IC of the UCD90197 family from Texas Instruments of Dallas, TX. The battery monitoring / charging device 978 may communicate the information about the battery 976 to the processor 952 via the interconnect 956. The battery monitoring / charging device 978 may also include an analog-to-digital converter (ADC) that enables the processor 952 to directly monitor the voltage of the battery 976 or the current flow from the battery 976. The battery parameters may be used to determine actions that edge computing node 950 may perform, such as transmission frequency, mesh network operation, detection frequency, and the like.A power block 980 or other power supply coupled to a power grid may be coupled to the battery monitoring / charging device 978 to charge the battery 976. In some examples, the power block 980 may be replaced with a wireless power receiver to wirelessly receive the power, for example, via a loop antenna in the edge computing node 950. A wireless battery charging circuit, such as, but not limited to, an LTC1640 chip from Linear Technologies of Milpitas, California, may be included in the battery monitoring / charging device 978. The specific charging circuits may be selected based on the size of the battery 976 and thus the required current. Charging may be performed using, among other things, the Airfuel standard sold by Airfuel Alliance, the Qi wireless charging standard sold by Wireless Power Consortium, or the Rezence charging standard sold by Alliance for Wireless Power.The storage 958 may include instructions 982 in the form of software, firmware, or hardware instructions for implementing the techniques described herein. Although such instructions 982 are shown as code blocks included in memory 954 and storage 958, it should be understood that any of the code blocks may be replaced with hardwired circuits integrated in, for example, an application specific integrated circuit (ASIC).In an example, the instructions 982 provided via the memory 954, the storage 958, or the processor 952 may be implemented as a non-transitory machine readable medium 960 comprising code to direct the processor 952 to perform electronic operations in the edge computing node 950. Processor 952 may access non-transitory machine readable medium 960 via interconnect 956. For example, the non-transitory machine-readable medium 960 may be implemented by devices described for storage 958, or may include specific storage devices, such as storage devices and / or storage disks including optical disks (e.g., digital versatile disk (DVD), compact disk (CD), CD-ROM, blu-ray disk), flash drives, floppy disks, hard disks (e.g., SSDs), or any number of other hardware devices in which information is stored for any duration (e.g., for extended periods of time, permanently, for short instances, for temporarily buffering, and / or caching). The non-transitory machine-readable medium 960 may include instructions to direct the processor 952 to perform a particular sequence or sequence of actions, such as described with reference to the one or more flowcharts and block diagrams of operations and functionality presented above. As used herein, the terms "machine-readable medium" and "computer-readable medium" are interchangeable. The term "non-transitory computer readable medium" is expressly defined herein to include any type of computer readable storage medium and / or storage disk and to exclude the transmission of signals and transmission media.Also in a specific example, the instructions 982 on the processor 952 (separately or in combination with the instructions 982 of the machine readable medium 960) may configure execution or operation of a trusted execution environment (TEE) 990. In one example, the TEE 990 operates as a protected area that is accessible to the processor 952 for secure execution of instructions and access to data. Various implementations of the TEE 990 and an accompanying secure area in the processor 952 or the memory 954 may be provided, for example, by using Intel® software guard extensions (SGX), or ARM® TrustZone® hardware security extensions, Intel® management engine (ME), or Intel® converged security management engine (CSME). Other aspects of security hardening, hardware trust anchors, and trusted or protected operations may be implemented in device 950 by TEE 990 and processor 952.FIG. 10 is a block diagram showing an overview of an edge computing configuration including a processing layer referred to as an "edge cloud" in many of the following examples. As shown, the edge cloud 1010 is commonly located at an edge location, such as an access point or base station 1040, a local processing hub 1050, or a center 1020, and may thus include multiple entities, devices, and device instances. The edge cloud 1010 is located much closer to the endpoint (consumer and producer) data sources 1060 (e.g., autonomous vehicles 1061, user device 1062, business and industrial device 1063, video capture devices 1064, drones 1065, smart cities and building devices 1066, sensors and IoT devices 1067, etc.) than the cloud data center 1030. Compute, storage, and storage resources offered at the boundaries in the edge cloud 1010 are critical to providing ultra low latency response times for services and functions used by the endpoint data sources 1060, as well as to reducing network backhaul traffic from the edge cloud 1010 to the cloud data center 1030, thereby improving power consumption and overall network uses, among other advantages.Computation, storage, and storage are tight resources and generally decrease depending on edge location (e.g., with less processing resources available at consumer endpoint devices than at a base station than at a center). However, the closer the edge location is to the endpoint (e.g., terminal (UE)), the more space and power are often limited. Thus, edge computing attempts to reduce the amount or number of resources needed for network services by distributing more resources that are closer both geographically and in network access time. In this way, edge computing attempts to bring the compute resources to the workload data, if any, or to bring the workload data to the compute resources.Aspects of an edge cloud architecture that covers multiple potential deployments and accounts for restrictions that some network operators or service providers might have in their own infrastructures are described below. These include variation of configurations based on the edge location (because edges at a base station level may have more constrained performance and capabilities, for example, in a multi-tenant scenario); configurations based on the type of computation, storage, storage, fabric, acceleration, or similar resources available to edge locations, levels of locations, or groups of locations; the service, security, and management and orchestration capabilities; and associated goals to achieve the utility and performance of end services. These inserts may accomplish processing in network layers, which may be considered "near edge", "close edge", "local edge", "middle edge", or "far edge" layers depending on latency, distance, and timing characteristics.Edge computing is an emerging paradigm in which data processing is performed at or closer to the edge (edge) of a network, typically by the use of a computing platform (e.g., x86 or ARM computing hardware architecture) implemented at base stations, gateways, network routers, or other devices that are much closer to endpoint devices that generate and consume the data. Edge gateway servers may be equipped with pools of search and storage resources, for example, to perform real-time computation for low latency use cases (e.g., autonomous driving or video monitoring) for connected client devices. Or as an example, base stations may be enhanced with computational and acceleration resources to directly process service workloads for connected user equipment without further communicating data over backhaul networks. Or as another example, central office network management hardware may be replaced with standardized computational hardware that performs virtualized network functions and provides computational resources for performing services and consumer functions for connected devices. Within edge computing networks, there may be scenarios in services in which the compute resource is "moved" to the data, as well as scenarios in which the data is "moved" to the compute resource. Or as an example, base station computation, acceleration, and network resources may provide services to scale workload requirements as needed by enabling quiescent capacity (subscription, capacity as needed) to manage corner cases, incidents, or provide longevity for deployed resources over a substantially longer life cycle implemented.FIG. 11 illustrates operating layers between endpoints, an edge cloud, and cloud computing environments 1100, according to an embodiment. In particular, FIG. 11 illustrates examples of computing application cases 1105 where the edge cloud 1110 is used at multiple illustrative levels of network computation, such as use of the edge cloud 1010 as shown in FIG. 10. The layers begin at an endpoint layer (device and things layer) 1100 that accesses the edge cloud 1110 to perform data application, analysis, and consumption activities. The edge cloud 1110 may span multiple network layers, such as an edge device layer 1111 with gateways, on-site servers, or network devices (nodes 1115) located in physically proximate edge systems; a network access layer 1120 including base stations, radio processing units, network hubs, regional data centers (DC), or local network devices (devices 1125); and any devices, devices, or nodes located therebetween (in layer 1112, not illustrated in detail). Network communications within the edge cloud 1110 and among the various layers may occur over any number of wired or wireless media, including via connectivity architectures and technologies not shown.Examples of latency resulting from network communication removal and processing schedules may range from less than one millisecond (ms) when in the middle of endpoint layer 1100, below 5 ms at edge device layer 1110, to even between 10 and 40 ms when communicating with nodes at network access layer 1120. Beyond the edge cloud 1110, layers of the core network 1130 and the cloud data center 1140 are each located with increasing latency (e.g., between 50 to 60 ms at the core network layer 1130 to 100 or more ms at the cloud data center layer). As a result, operations at a core network data center 1135 or cloud data center 1145 with latencies of at least 50 to 100 ms or more will not be able to implement many time critical functions of use cases 1105. Each of these latency values is provided for illustrative and contrast purposes; it should be appreciated that the use of other access network media and technologies may further reduce latencies. In some examples, respective portions of the network relating to a network source and a network destination may be categorized as "close edge", "local edge", "near edge", "middle edge", or "far edge" layers. For example, from the perspective of the core network data center 1135 or cloud data center 1145, a center or content data network may be considered to be within a near edge layer ("near" the cloud, with high latency values when communicating with the devices and endpoints of the use cases 1105), whereas an access point, base station, on-site server, or network gateway may be considered to be within a far edge layer ("far" from the cloud, with low latency values when communicating with the devices and endpoints of the use cases 1105). It should be appreciated that categorizations of a particular network layer other than a "close", "local", "near", "middle", or "far" edge may be based on latency, distance, number of network hops, or other measurable characteristics as measured by a source in any of the network layers 1100- 1140.The various use cases 1105 may access resources under usage pressure of incoming streams due to multiple services that the edge cloud uses. To achieve low latency results, the services executing within the edge cloud 1110 resemble varying requirements in terms of: (a) priority (throughput or latency) and quality of service (QoS) (e.g., traffic for an autonomous car may have a higher priority than a temperature sensor in terms of response time requirement; or performance sensitivity / bottleneck may exist on a compute / accelerator, storage, storage, or network resource depending on the application); (b) Reliability and Resistivity (e.g., some input currents must be processed and traffic routed with mission critical reliability, whereas some other input currents may tolerate occasional failure depending on the application); and (c) physical constraints (e.g., power, cooling, and form factor).The end-to-end service view for these use cases involves the concept of service flow and is associated with a transaction. The transaction specifies the overall service request for the entity that consumes the service, as well as the associated services for the resources, workloads, workflows, and business function and business level requests. The services executing with the described "conditions" may be managed at each layer in a manner to ensure real-time and runtime contract conformance for the transaction during the life cycle of the service. If a component in the transaction fails its Agreed Service Level Agreement (SLA), the system as a whole may provide (components in the transaction) the capability to (1) understand the impact of the SLA violation and (2) extend other components in the system to resume all the transaction SLA, and (3) implement remedial actions.Accordingly, considering these variations and service features, edge computing within the edge cloud 1110 may provide the ability to supply and respond to multiple applications of the use cases 1105 (e.g., object tracking, video monitoring, connected cars, etc.) in real-time or near real-time and meet ultra low latency requirements for these multiple applications. These advantages enable a new class of applications (e.g., virtual network functions (VNFs), function as a service (FaaS), edge as a service (EaaS), standard processes, etc.) that cannot utilize conventional cloud computing due to latencies or other constraints.However, the following reservations are also associated with the advantages of edge computing. The devices that are located at the edge are often resource constrained so that the use of the edge resources is under pressure. Typically, this is addressed by pooling memory and storage resources for use by multiple users (tenants) and devices. The edge may be limited in power and cooling, such that power consumption must be accounted for by the applications that consume most of the power. There may be inherent tradeoffs in power supply performance in these bundled memory resources because many of them are likely to use newly emerging memory technologies where more power requires a larger memory bandwidth. Similarly, improved security of hardware and trusted root functions are also required, as edge locations may be unmanned and may even require permitted access (e.g., when housed at a third party location). Such problems are compounded in the edge cloud 1110 in a multi-tenant, multi-owner, or multi-access setting in which services and applications are requested by many users, particularly as network usage varies dynamically and the composition of the plurality of postholders, use cases, and services changes.At a more generic level, an edge computing system may be described as including any number of deployments at the layers discussed above that operate in the edge cloud 1110 (network layers 1100-1140) that provide coordination from the client and distributed computing devices. One or more edge gateway nodes, one or more edge aggregation nodes, and one or more core data centers may be distributed across layers of the network to provide an implementation of the edge computing system by or on behalf of a telecommunications service provider ("telco" or "TSP"), Internet of Things service provider, cloud service provider (CSP), enterprise entity, or any other number of entities. Various implementations and configurations of the edge computing system may be provided dynamically, such as when orchestrated to meet service objectives.In accordance with the examples provided herein, a client computing node as any type of endpoint component, device, device, or otherwise may be capable of communicating as a producer or consumer of data. Further, the term "node" or "device" as used in the edge computing system does not necessarily mean that such node or device operates in a client or agent / minion / follower role; rather, any of the nodes or devices in the edge computing system refer to individual entities, nodes, or subsystems that include discrete or interconnected hardware or software configurations to enable or use the edge cloud 1110.As such, the edge cloud 1110 is formed from network components and functional features that operate by and within edge gateway nodes, edge aggregation nodes, or other edge computing nodes under the network layers 1110- 1130. The edge cloud 1110 may thus be implemented as any type of network that provides edge computing and / or storage resources that are proximate to radio access network, RAN, enabled endpoint devices (e.g., mobile computing devices, IoT devices, smart devices, etc.) discussed herein. In other words, the edge cloud 1110 may be thought of as an "edge" connecting the endpoint devices and traditional network access points serving as an entry point into service provider core networks, including mobile bearer networks (e.g., Global System for Mobile Communications (GSM) networks, Long-Term Evolution (LTE) networks, 5G / 6G networks, etc.), while also providing storage and / or computing capabilities. Other types and forms of network access (e.g., WiFi, long-range wireless networks, wired networks, including optical networks) may also be used in place of or in combination with such 3GPP carrier networks.The network components of the edge cloud 1110 may be servers, tenant servers, device computing devices, and / or any other type of computing device. For example, the edge cloud 1110 may include a device computing device that is a stand-alone electronic device including a housing, a chassis, a shell, or a shell. In some circumstances, the housing may be dimensioned for portability so that it may be worn and / or shipped by a human. Example enclosures may include materials forming one or more exterior surfaces that partially or fully protect contents of the device, where the protection may include weather protection, protection in hazardous environments (e.g., electromagnetic interference (EMI), vibration, extreme temperatures, etc.), and / or enable introdibility. Example enclosures may include power circuitry to provide power for stationary and / or portable implementations, such as alternating current (AC) inputs, direct current (DC) inputs, AC / DC converters, DC / AC converters, DC / DC converters, power controllers, transformers, charging circuitry, batteries, wired inputs, and / or wireless power inputs. Example housings and / or surfaces thereof may include or be connected to mounting hardware to enable attachment to structures such as buildings, telecommunications structures (e.g., towers, antenna structures, etc.), and / or racks (e.g., server racks, blade mounts, etc.). Example housings or surfaces thereof may support one or more sensors (e.g., temperature sensors, vibration sensors, light sensors, acoustic sensors, capacitive sensors, proximity sensors, infrared or other visual thermal sensors, etc.). One or more such sensors may be included in, supported by, or otherwise embedded within, and / or mounted on the surface of the device. Example housings and / or surfaces thereof may support mechanical connectivity, such as drive hardware (e.g., wheels, rotors such as propellers, etc.) and / or articulation hardware (e.g., robotic arms, pivotable extensions, etc.). In some circumstances, the sensors may include any type of input device, such as user interface hardware (e.g., buttons, switches, dials, sliders, microphones, etc.). In some circumstances, the housings include dispensers contained therein, supported by, embedded in, and / or attached to them. Output devices may include displays, touch screens, lights, light emitting diodes (LEDs), speakers, input / output (e.g., Universal Serial Bus (USB)), etc. Edge devices may be devices deployed on the network for a specific purpose (e.g., a traffic light), but may have processing or other capabilities that may be utilized for other purposes. Such edge devices may be independent of other networked devices and may be provided with a housing having a form factor suitable for its primary purpose; yet still available for other computing tasks that do not interfere with their primary task. Edge devices include Internet of Things devices. The device computing device may include hardware and software components to manage local factors such as device temperature, vibration, resource utilization, updates, performance aspects, physical and network security, etc. Example hardware for implementing a device computing device is described in connection with FIG. 9B. The edge cloud 1110 may also include one or more servers and / or one or more tenant-enabled servers. Such a server may include an operating system and implement a virtual computing environment. A virtual computing environment may include a hypervisor that manages (e.g., creates, inserts, provides, destroys, de-operates, etc.) one or more virtual machines, containers, etc. Such virtual computing environments provide an execution environment in which one or more applications and / or other software, code, or scripts may be executed while being isolated from one or more other applications, software, code, or scripts.FIG. 12 illustrates an example approach for networking and services in an edge computing system, according to an embodiment. In FIG. 12, various client endpoints 1210 (in the form of mobile devices, computers, autonomous vehicles, business computing facilities, industrial processing facilities) exchange requests and responses specific to the type of endpoint network aggregation. For example, client endpoints 1210 may obtain network access over a broadband wired network by exchanging requests and responses 1222 through an on-site network system 1232. Some client endpoints 1210, such as mobile computing devices, may obtain network access over a broadband wireless network by exchanging requests and responses 1224 through an access point (e.g., cell tower) 1234. Some client endpoints 1210, such as autonomous vehicles, may receive network access for requests and responses 1226 over a wireless vehicle network through a road network system 1236. However, regardless of the type of network access, the TSP may provide aggregation points 1242 and 1244 within the edge cloud 1210 to aggregate traffic and requests, e.g., use of the edge cloud 1010 as shown in FIG. 10 or use of the edge cloud 1110 as shown in FIG. 11. Thus, the TSP within the edge cloud 1210 may employ various computing and storage resources, such as at edge aggregation nodes 1240, to provide requested content. The edge aggregation nodes 1240 and other systems of the edge cloud 1210 are connected to a cloud or data center 1260 that uses a backhaul network 1250 to satisfy higher latency requirements from a cloud / data center for websites, applications, database servers, etc. Additional or consolidated instances of the edge aggregation nodes 1240 and aggregation points 1242, 1244, including those deployed on a single server framework, may also be present within the edge cloud 1210 or other portions of the TSP infrastructure.FIG. 13 illustrates an example software distribution platform 1305 for distributing software, according to an embodiment. The software distribution platform 1305 may include computer readable instructions 1382 (e.g., computer readable instructions 982 of FIG. 9B ) for one or more devices, such as example processor platform(s) 1315 and / or example connected edge devices 1111 of FIG. 11. The example software distribution platform 1305 may be implemented by any computer server, data appliance, cloud service, etc., capable of storing software and transmitting it to other computing devices (e.g., to third party, the example connected edge devices 1111 of FIG. 11 ). Example connected edge devices may be clients, clients, management devices (e.g., servers), third party (e.g., clients of an entity that owns and / or operates the software distribution platform 1305). Example connected edge devices may operate in commercial and / or home automation environments. In some examples, a third party is a developer, a seller, and / or a licenser of software, such as the example computer readable instructions 1382. The third party may be consumers, users, retailers, OEMs, etc., who purchase and / or license the software for use and / or resale and / or subliticking. In some examples, distributed software causes a display of one or more user interfaces (UIs) and / or graphical user interfaces (GUIs) to identify the one or more devices (e.g., connected edge devices) geographically and / or logically separated from each other (e.g., physically separated IoT devices, ordered with responsibility for water distribution control (e.g., pumps), power distribution control (e.g., relays), etc.).In the illustrated example of FIG. 13, the software distribution platform 1305 includes one or more servers and one or more storage devices. The memory devices store the computer readable instructions 1382 that, as described above, may correspond to the example computer readable instructions 982 of FIG. 9B. The one or more servers of the example software distribution platform 1305 are in communication with a network 1310, which may correspond to any one or more of the Internet and / or any of the example networks described above. In some examples, the one or more servers are responsive to requests to transmit the software to a requesting party as part of a commercial transaction. Payment for the delivery, sale, and / or license of the software may be handled by the one or more servers of the software distribution platform and / or via a third party payment entity. The servers enable buyers and / or licensees to download the computer readable instructions 982 from the software distribution platform 1305. For example, the software may be downloaded to the example processor platform(s) 1315 (e.g., connected edge devices) that is to execute the computer readable instructions 1382 to implement non-dominant resource management for tenant-enabled edge applications. In some examples, one or more servers of the software distribution platform 1305 are communicatively coupled to one or more security domains and / or devices through which requests and transmissions of the example computer readable instructions 1382 must pass. In some examples, one or more servers of the software distribution platform 1305 periodically offer, transmit, and / or force updates to the software (e.g., computer readable instructions 1382) to ensure improvements, patches, updates, etc., are distributed and applied to the software at the end user devices.In the illustrated example of FIG. 13, the computer readable instructions 1382 are stored on storage devices of the software distribution platform 1305 in a particular format. A format of computer readable instructions includes, but is not limited to, a particular code language (e.g., Java, JavaScript, Python, C, C#, SQL, HTML, etc.) and / or a particular code state (e.g., uncompilation code (e.g., ASCII), interpretation code, association code, executable code (e.g., a binary), etc.). In some examples, the computer readable instructions 982 stored in the software distribution platform 1305 are in a first format when transmitted to the example processor platform(s) 1315. In some examples, the first format is an executable binary in which certain types of processor platform(s) 1315 may be executed. However, in some examples, the first format is uncompilation code that requires one or more preparation tasks to convert the first format to a second format to enable execution on the example processor platform(s) 1315. For example, the receiving processor platform(s) 1315 may need to compile the computer readable instructions 1382 in the first format to generate executable code in a second format capable of executing on the processor platform(s) 1315. In still other examples, the first format is interpreted code that is interpreted by an interpreter upon reaching the processor platform(s) 1315 to facilitate execution of instructions.FIG. 14 illustrates an example of an infrastructure processing unit (IPU). Various examples of IPUs disclosed herein enable enhanced performance, management, security, and coordination functions between entities (e.g., cloud service providers) and enable infrastructure offload or communication coordination functions. As disclosed in more detail below, IPUs may be integrated with smartNICs and working or mass storage (e.g., on the same die, system-on-a-chip (SoC), or connected dies) located on-site systems, base stations, gateways, neighborhood centers, etc. Various examples of one or more IPUs disclosed herein may perform an application, including any number of microservices, where each microservice runs in its own process and communicates using protocols (e.g., via an HTTP resource API, a message service, or gRPC). Microservices can be independently deployed by centrally managing these services. A management system may be written in different programming languages and use different data storage technologies.Further, one or more IPUs may perform platform management, networking batch processing operations, security (crypto) operations, storage software, identity and key management, telemetry, logging, monitoring, and a service mesh (e.g., controlling how different microservices communicate with each other). The IPU may access an xPU to offload execution of various tasks. For example, an IPU XPU, storage, storage, and CPU discloses resources and capabilities as one service that can be accessed by other microservices for functional composition. This may improve performance and reduce data movement and latency. An IPU may perform functions such as router, load balancing, firewall, TCP / reliable transport, service mesh (e.g., proxy or API gateway), security, data transformation, authentication, quality of service (QoS), security, telemetry measurement, event logging, data stream initiation and management, data placement or order scheduling of resources on an xPU, memory, storage, or CPU.In the illustrated example of FIG. 14, the IPU 1400 includes or otherwise accesses secure resource management circuitry 1402, network interface control, NIC, circuitry 1404, security and trust anchor circuitry 1406, resource composition circuitry 1408, timestamp management circuitry 1410, memory and storage 1412, processing circuitry 1414, accelerator circuitry 1416, or translation circuitry 1418. Any number or combination of one or more other structures may be used, such as, but not limited to, compression and encryption circuitry 1420, memory management and translation unit circuitry 1422, compute fabric data switching circuitry 1424, security policy enforcement circuitry 1426, device virtualization circuitry 1428, telemetry, tracking, logging and monitoring circuitry 1430, quality of service circuitry 1432, search circuitry 1434, network function circuitry (e.g., routing, firewall, load balancing, network address translation (NAT), etc.) 1436, reliable transport, ordering, retransmission, overload control circuitry 1438, and high availability, error handling, and migration circuitry 1440, As shown in FIG. 14, various examples may use one or more structures (components) of the example IPU 1400 together or separately. For example, compression and encryption circuitry 1420 may be used as a separate service or concatenated as part of a data flow with vSwitch and packet encryption.In some examples, the IPU 1400 includes a field programmable gate array (FPGA) 1470 structured to receive commands from a CPU, XPU, or application via an API and perform commands / tasks on behalf of the CPU, including workload management and offload or accelerator operations. The illustrated example of FIG. 14 may include any number of FPGAs configured or otherwise structured to perform any operations of any IPU described herein.The example computing fabric circuitry 1450 provides connectivity to a local host or device (e.g., server or device (e.g., xPU, storage or storage device)). Connectivity to a local host or device or SmartNIC or other IPU is achieved using peripheral component interconnect express (PCIe) and / or ARM AXI and / or Intel® quick path interconnect (QPI), and / or Intel® ultra path interconnect (UPI), and / or Intel® on-chip system fabric (IOSF), and / or omnipath and / or Ethernet and / or compute express link (CXL), and / or HyperTransport and / or NVLink, and / or Advanced Microcontroller Bus Architecture (AMBA), in some examples The invention is also directed to an interconnect and / or openCAPI and / or gen-Z and / or CCIX and / or Integrity Fabric (IF), and so forth. Different examples of host connectivity provide symmetric memory and symmetric caching to enable equal peering between CPU, XPU, and IPU (e.g., via CXL.cache and CXL.mem).Example media interface circuitry 1460 provides connectivity to a remote SmartNIC or other IPU or service via a network medium or fabric. This may be provided over any type of network media (e.g., wired or wireless) and using any protocol (e.g., Ethernet, InfiniBand, Fiber Channel, ATM, et al.).In some examples, rather than the server / CPU being the primary component that the IPU 1400 manages, the IPU 1400 is a root of a system (e.g., a rack of servers or a data center) and manages computing resources (e.g., CPU, xPU, storage, storage, other IPUs, etc.) in the IPU 1400 and external to the IPU 1400. Various operations of an IPU will be described below.In some examples, the IPU 1400 performs orchestration to decide which hardware or software should execute a workload based on available resources (e.g., services and devices) and accounts for quality of service agreements and latencies to determine whether resources (e.g., CPU, xPU, storage, storage, etc.) should be allocated by the local host or by a remote host or a pooled resource. In examples where the IPU 1400 is selected to perform a workload, the secure resource management circuitry 1402 swaps work to a CPU, xPU, or other device, and the IPU 1400 speeds up the connectivity of distributed runtimes, reduces latency, CPU, and increases reliability.In some examples, the secure resource management circuitry 1402 executes a service mesh to decide which resource the workload should execute and cause L7 (application layer) and remote procedure call (RPC) traffic to completely bypass the kernel so that an application in the user space can communicate directly with the example IPU 1400 (e.g., the IPU 1400 and the application can share a storage space). In some examples, a service mesh is a configurable low-latency infrastructure layer configured to handle communication between application microservices using application programming interfaces (APIs) (e.g., via remote procedure calls (RPCs)). The example service mesh provides quick, reliable, and secure communication between containerized or virtualized application infrastructure services. The service mesh may provide critical capabilities including, but not limited to, service discovery, load balancing, encryption, observability, traceability, authentication and authorization, as well as support for the disconnect switch pattern.In some examples, infrastructure services include a federation node that is generated by an IPU upon or upon receipt of a workload from an application. In some cases, the federation node includes access to hardware devices, software using APIs, RPCs, gRPs, or communication protocols with instructions such as iSC, NVMe-oF, CXL, among others.In some cases, the example IPU 1400 dynamically chooses itself to execute a given workload (e.g., microservice) within a configurable infrastructure including an IPU, xPU, CPU, storage, memory, and other devices in a node.In some examples, communications through media interface circuitry 1460 of example IPU 1400 pass through a NIC / smart NIC (for internode communications) or back to a local service on the same host. Communications through the example media interface circuitry 1460 of the example IPU 1400 to another IPU may then use shared storage support transport between xPUs switched by the local IPUs. The use of IPU-to-IPU communication may reduce latency and jitter through message entry scheduling and work processing based on a Service Level Objective (SLO).For example, for a request to a database application that requires a response, the example IPU 1400 prioritizes its processing to minimize the stalling of the requesting application. In some examples, the IPU 1400 schedules the prioritized message request that issues the event to execute an SQL query database, and the example IPU constructs microservices that issue SQL queries, and the queries are sent to the corresponding devices or services.The examples described herein may include or operate with logic or a series of components, modules, or mechanisms. The modules may be hardware, software, or firmware communicatively coupled to one or more processors to perform the operations described herein. The modules may be hardware modules, and as such, the modules may be considered tangible entities that are capable of performing specific operations and may be configured or arranged in a particular manner. In one example, circuits may be arranged as a module in a specified manner (e.g., internally or with respect to external entities such as other circuits). In one example, one or more computer systems (e.g., a stand-alone, client, or server computer system) or one or more hardware processors may be configured in whole or in part by firmware or software (e.g., instructions, an application portion, or an application) as a module that serves to perform certain operations. In one example, the software may reside on a machine readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to include a tangible entity, whether it is an entity that is physically constructed, is separately configured (e.g., hardwired), or is temporarily (e.g., transitory) configured (e.g., programmed) to operate in a specified manner, or perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one time. For example, if the modules include a general purpose hardware processor configured using software, the general purpose hardware processor may be configured as different modules at different times, respectively. Software may accordingly configure a hardware processor, for example, to form a particular module at one time and to form another module at another time. Modules may also be software or firmware modules that operate to perform the methodologies described herein."Circuitry or circuits" as used herein may include, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors including one or more individual instruction processing cores, state machine circuitry, and / or firmware storing instructions executed by programmable circuitry. The circuits, circuitry, or modules may be collectively or individually implemented as circuitry that is part of a larger system, for example, an integrated circuit (IC), a system-on-a-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc.As used herein in any embodiment, the term "logic" may refer to firmware and / or circuitry configured to perform any of the aforementioned operations. Firmware may be embodied as code, instructions or instruction sets and / or data hard-coded (e.g., nonvolatile) in memory devices and / or circuitry."Circuitry" as used herein in any embodiment may include, for example, hardwired circuitry, programmable circuitry, state machine circuitry, logic, and / or firmware storing instructions executed by programmable circuitry, alone or in any combination. The circuit arrangement may be implemented as an integrated circuit, such as an integrated circuit chip. In some embodiments, the circuitry may be at least partially formed by processor circuitry executing code and / or instruction sets (e.g., software, firmware, etc.) corresponding / corresponding to the functionality described herein, thus correspondingly transforming a general purpose processor into a special purpose processing environment for performing one or more of the operations described herein. In some embodiments, the processor circuitry may be implemented as a stand-alone integrated circuit or incorporated as one of several components in an integrated circuit. In some embodiments, the various components and circuitry of the node or other systems may be combined in a system-on-a-chip, SoC, architecture.The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings illustrate specific embodiments that may be practiced. These embodiments are also referred to herein as "examples.". Such examples may include additional elements in addition to those elements shown or described. However, examples are also conceivable which contain the elements shown or described. Moreover, examples are also conceivable in which any combination or permutation of the elements shown or described (or one or more aspects thereof) is used, either with respect to a particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, regardless of other instances or uses of "at least one" or "one or more.". In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B", "B but not A", and "A and B", unless otherwise indicated. In the appended claims, the terms "including / including" and "in which" are used as easily understood equivalents of the respective terms "comprising" and "wherein.". Moreover, in the following claims, the terms "including" and "comprising" are used open-ended, that is, a system, apparatus, article, or process that includes elements in addition to those listed after such term in a claim are still considered to fall within the scope of that claim. Moreover, in the following claims, the terms "first", "second", and "third", etc. are used merely as labels, and are not intended to indicate a numerical order for their objects.Each of the following non-limiting examples may stand alone or be combined with one or more of the other examples in various permutations or combinations.Example 1 is a system for secure and attestable function as a service, the system comprising: a first edge computing device comprising a first processor device and a first memory, the first memory including edge device instructions that, when executed by the first processor device, cause the first processor device to: receive a first service execution request, identify, based on the first service execution request, a first function as a service, and a second function as a service; send first function instructions to a second processor device on a second edge computing device to execute the first function as a service and return a first function response; sending second function instructions to a third processor device on a third edge computing device to execute the second function as a service and return a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.In Example 2, the subject matter of Example 1 includes, wherein the edge device instructions further cause the first processor device to: identify, based on the first service execution request, a third function as a service; and execute the third function as a service on the first processor device on the first edge computing device and return a third function response; wherein the service request result is further based on the third function response.In Example 3, the subject matter of Examples 1-2 includes, wherein the edge device instructions further cause the first processor device to: generate a first software-defined network at the first processor device based on the first service execution request, the first function as a service, and the second function as a service executing on the first software-defined network.In Example 4, the subject matter of Example 3 includes, wherein the edge device instructions further cause the first processor device to: access a function as a service chain from a first hard disk cache as storage in response to the first service execution request, wherein the first software defined network is generated based on the service chain.In Example 5, the subject matter of Examples 3-4 includes, wherein the edge device instructions further cause the first processor device to: destroy the first software-defined network in response to a first execution of the first function as a service.In Example 6, the subject matter of Examples 3-5 includes, wherein the edge device instructions further cause the first processor device to: receive a second computing request upon completion of the first service execution request, the second computing request comprising a request to execute the first function as a service and the second function as a service; authenticate a first security of the first software-defined network; and execute, responsive to the authentication of the first security of the first software-defined network, the first function as a service.In Example 7, the subject matter of Example 6 includes, wherein the edge device instructions further cause the first processor device to: determine that a security assessment period has elapsed since completion of the first service execution request, wherein the assessment of the first security is responsive to the determination that the security assessment period has elapsed.In Example 8, the subject matter of Example 7 includes, wherein the edge device instructions further cause the first processor device to: transmit, in response to the first security being tested, a first signal to the second processor device to execute the second function as a service.In Example 9, the subject matter of Examples 1-8 includes, a third processor device on the first edge computing device, wherein the edge device instructions further cause the first processor device to: identify, based on the first service execution request, a third function asa service; and send a second signal to the third processor to execute the third function asa service.In Example 10, the subject matter of Examples 1-9 includes, wherein: the first function asa service generates a first intermediate result that is executed at the first edge computing device; the second function asa service generates a second intermediate result based on the first intermediate result; and the service request result is generated based on the second intermediate result.In Example 11, the subject matter of Example 10 includes, wherein the edge device instructions further cause the first processor device to: access a first security context at the first processor device; and generate a first secure network connection between the first edge computing device and the second edge computing device based on the first security context, wherein the first intermediate result is sent over the first secure network connection.In Example 12, the subject matter of Example 11 includes, wherein the edge device instructions further cause the first processor device to: send a second security context from the second edge computing device to a second hard disk cache for storage after the first intermediate result is sent over the first secure network connection.In Example 13, the subject matter of Example 12 includes, wherein: the first security context is accessed from the second hard disk cache as a storage device to the first edge computing device; and the second security context is sent from the second edge computing device to the second hard disk cache as storage.In Example 14, the subject matter of Examples 1-13 includes, wherein: the first edge computing device is in networked communication with a second edge computing device; the first edge computing device is at a first location; and the second edge computing device is at a second location, the second location being different than the first location.In Example 15, the subject matter of Examples 1-14 includes, wherein the first processor device comprises at least one of a logical processor device and a physical processor device.Example 16 is at least one machine readable storage medium including edge device instructions that, in response to being executed with processor circuitry of a computer controlled device, cause the processor circuitry to: receive a first service execution request at a first edge computing device, the first edge computing device comprising a first processor and a first memory; identify, based on a first service execution request, a first function as a service, and a second function as a service; send first function instructions to a second processor device on a second edge computing device to execute the first function as a service and provide a first function response; sending second instructions to a third processor device on a third edge computing device to execute the second function as a service and provide a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.In Example 17, the subject matter of Example 16 includes, wherein the edge device instructions further cause the processor circuitry to: identify, based on the first service execution request, a third function as a service; and execute the third function as a service on the first processor device on the first edge computing device and return a third function response; wherein the service request result is further based on the third function response.In Example 18, the subject matter of Examples 16-17 includes, wherein the edge device instructions further cause the processor circuitry to: generate a first software-defined network at the first processor device based on the first service execution request, the first function as a service, executing on the first software-defined network.In Example 19, the subject matter of Example 18 includes, wherein the edge device instructions further cause the processor circuitry to: access a function as a service chain from a first hard disk cache as storage in response to the first service execution request, wherein the first software defined network is generated based on the service chain.In Example 20, the subject matter of Examples 18-19 includes, wherein the edge device instructions further cause the processor circuitry to: destroy the first software-defined network in response to a first execution of the first function as a service.In Example 21, the subject matter of Examples 18-20 includes, wherein the edge device instructions further cause the processor circuitry to: receive a second compute request upon completion of the first service execution request, the second compute request comprising a request to execute the first function as a service and the second function as a service; attach a first security of the first software defined network; and execute, responsive to the attach the first security of the first software defined network, the first function as a service.In Example 22, the subject matter of Example 21 includes, wherein the edge device instructions further cause the processor circuitry to: determine that a security assessment period has elapsed since completion of the first service execution request, wherein the assessment of the first security is responsive to the determination that the security assessment period has elapsed.In Example 23, the subject matter of Example 22 includes, wherein the edge device instructions further cause the processor circuitry to: transmit, in response to the first security being tested, a first signal to the second processor device to execute the second function as a service.In Example 24, the subject matter of Examples 16-23 includes the edge device instructions that further cause the processor circuitry to: identify, based on the first service execution request, a third function as a service; and send a second signal to a third processor device on the first edge computing device to execute the third function as a service.In Example 25, the subject matter of Examples 16-24 includes, wherein: the first function as a service generates a first intermediate result that is executed at the first edge computing device; the second function as a service generates a second intermediate result based on the first intermediate result; and the service request result is generated based on the second intermediate result.In Example 26, the subject matter of Example 25 includes, wherein the edge device instructions further cause the processor circuitry to: access a first security context at the first processor device; and generate a first secure network connection between the first edge computing device and the second edge computing device based on the first security context, wherein the first intermediate result is sent over the first secure network connection.In Example 27, the subject matter of Example 26 includes, wherein the edge device instructions further cause the processor circuitry to: send a second security context from the second edge computing device to a second hard disk cache for storage after the first intermediate result is sent over the first secure network connection.In Example 28, the subject matter of Example 27 includes, wherein: the first security context is accessed from the second hard disk cache as a storage device to the first edge computing device; and the second security context is sent from the second edge computing device to the second hard disk cache as storage.In Example 29, the subject matter of Examples 16-28 includes, wherein: the first edge computing device is in networked communication with a second edge computing device; the first edge computing device is at a first location; and the second edge computing device is at a second location, the second location being different than the first location.In Example 30, the subject matter of Examples 16-29 includes, wherein the first processor device comprises at least one of a logical processor device and a physical processor device.Example 31 is a method for secure and attestable function as a service, the method comprising: receiving a first service execution request at a first edge computing device, the first edge computing device comprising a first processor device and a first memory; identifying, based on a first service execution request, a first function as a service and a second function as a service; sending first function instructions to a second processor device on a second edge computing device to execute the first function asa service and return a first function response; sending second function instructions to a third processor device on a third edge computing device to execute the second function as a service and provide a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.In Example 32, the subject matter of Example 31 includes, identifying, based on the first service execution request, a third function as a service; and executing the third function as a service on the first processor device on the first edge computing device and returning a third function response; wherein the service request result is further based on the third function response.In Example 33, the subject matter of Examples 31-32 includes, generating a first software-defined network at the first processor device based on the first service execution request, the first function as a service executing on the first software-defined network.In Example 34, the subject matter of Example 33 includes, reading to a function as a service chain from a first disk cache as storage in response to the first service execution request, wherein the first software defined network is generated based on the service chain.In Example 35, the subject matter of Examples 33-34 includes, destroying the first software-defined network in response to a first execution of the first function as a service.In Example 36, the subject matter of Examples 33-35 includes, receiving a second compute request after completion of the first service execution request, wherein the second compute request includes a request to execute the first function as a service and the second function as a service; assaying a first security of the first software-defined network; and executing, in response to the assaying the first security of the first software-defined network, the first function as a service.In Example 37, the subject matter of Example 36 includes, determining that a security assessment period has elapsed since completion of the first service execution request, wherein the first security assessment is responsive to the determination that a security assessment period has elapsed.In Example 38, the subject matter of Example 37 includes, responsive to the first security being tested, sending a first signal to the second processor device to execute the second function as a service.In Example 39, the subject matter of Examples 31-38 includes, identifying, based on the first service execution request, a third function as a service; and sending a second signal to a third processor device on the first edge computing device to execute the third function as a service.In Example 40, the subject matter of Examples 31-39 includes, wherein: the first function as a service generates a first intermediate result that is executed at the first edge computing device; the second function as a service generates a second intermediate result based on the first intermediate result; and the service request result is generated based on the second intermediate result.In Example 41, the subject matter of Example 40 includes, at the first processor device, reading into a first security context; and generating a first secure network connection between the first edge computing device and the second edge computing device based on the first security context, wherein the first intermediate result is sent over the first secure network connection.In Example 42, the subject matter of Example 41 includes, offloading a second security context from the second edge computing device after the first intermediate result is sent over the first secure network connection.In Example 43, the subject matter of Example 42 includes, wherein: the first security context is accessed from a second hard disk cache as a storage device to the first edge computing device; and the second security context is sent from the second edge computing device to the second hard disk cache as storage.In Example 44, the subject matter of Examples 31-43 includes, wherein: the first edge computing device is in networked communication with a second edge computing device; the first edge computing device is at a first location; and the second edge computing device is at a second location, the second location being different than the first location.In Example 45, the subject matter of Examples 31-44 includes, wherein the first processor device includes at least one of a logical processor device and a physical processor device.Example 46 is a first edge computing device, comprising: a first processor device and a first memory, the first memory comprising edge device instructions, which when executed by the first processor device, cause the first processor device to: identify, based on the first service execution request, a first function as a service and a second function as a service; execute the first function as a service on the first processor device; send second instructions to a second processor device on a second edge computing device to execute the second function as a service and provide a response; and return a service request result of the first service execution request based on the response.Example 47 is at least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-46.Example 48 is an apparatus comprising means for implementing any of Examples 1-46.Example 49 is a system for implementing any of Examples 1-46.Example 50 is a method of implementing any of Examples 1-46.The foregoing description is intended to be illustrative and not limiting. For example, the examples described above (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art after review of the above description. The Abstract is intended to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will be used to interpret or limit the scope or meaning of the claims. In addition, in the above detailed description, various features may be grouped together to further emphasize the disclosure. However, the claims may not present every feature disclosed herein, as embodiments may include a subset of those features. Moreover, embodiments may also include fewer features than set forth in a particular example. Therefore, the following claims are incorporated into the Detailed Description, with a claim standing on its own as a stand-alone embodiment. The scope of the embodiments disclosed herein should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

A system for secure and attestable function as a service, the system comprising: a first edge computing device comprising a first processor device and a first memory, the first memory comprising edge device instructions that, when executed by the first processor device, cause the first processor device to: receive a first service execution request; identify, based on the first service execution request, a first function as a service and a second function as a service; send first function instructions to a second processor device on a second edge computing device to execute the first function as a service and return a first function response; sending second function instructions to a third processor device on a third edge computing device to execute the second function as a service and return a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.The system of claim 1, wherein the edge device instructions further cause the first processor device to: identify, based on the first service execution request, a third function as a service; and execute the third function as a service at the first processor device at the first edge computing device and return a third function response; wherein the result of the service request is further based on the third function response.The system of any of claims 1-2, wherein the edge device instructions further cause the first processor device to: generate a first software-defined network at the first processor device based on the first service execution request, the first function as a service, and the second function as a service executing on the first software-defined network.The system of claim 3, wherein the edge device instructions further cause the first processor device to: access a function as a service chain from a first hard disk cache as storage in response to the first service execution request; wherein the first software defined network is generated based on the service chain.The system of any of claims 3-4, wherein the edge device instructions further cause the first processor device to: destroy the first software-defined network in response to a first execution of the first function as a service.The system of any of claims 3-5, wherein the edge device instructions further cause the first processor device to: receive a second computing request upon completion of the first service execution request; wherein the second computing request comprises a request to execute the first function as a service and the second function as a service; authenticate a first security of the first software defined network; and execute, in response to the authenticating, the first security of the first software defined network, the first function as a service (function as a service).The system of claim 6, wherein the edge device instructions further cause the first processor device to: determine that a security assessment period has elapsed since completion of the first service execution request, wherein the assessment of the first security is responsive to the determination that the security assessment period has elapsed.The system of claim 7, wherein the edge device instructions further cause the first processor device to: transmit, in response to the first security being tested, a first signal to the second processor device to execute the second function as a service.The system of any of claims 1-8, further comprising a third processor device on the first edge computing device, wherein the edge device instructions further cause the first processor device to: identify, based on the first service execution request, a third function as a service; and send a second signal to the third processor device to execute the third function as a service.The system of any of claims 1-9, wherein: the first function as a service generates a first intermediate result that is executed on the first edge computing device; the second function as a service generates a second intermediate result based on the first intermediate result; and the result of the service request is generated based on the second intermediate result.The system of claim 10, wherein the edge device instructions further cause the first processor device to: access a first security context on the first processor device; and generate a first secure network connection between the first edge computing device and the second edge computing device based on the first security context; wherein the first intermediate result is sent over the first secure network connection.The system of claim 11, wherein the edge device instructions further cause the first processor device to: send a second security context from the second edge computing device to a second hard disk cache for storage after the first intermediate result is sent over the first secure network connection.At least one machine readable storage medium including edge device instructions that, in response to being executed with processor circuitry of a computer controlled device, cause the processor circuitry to: receive a first service execution request on a first edge computing device, the first edge computing device comprising a first processor device and a first memory; identify, based on the first service execution request, a first function as a service and a second function as a service; send first function instructions to a second processor device on a second edge computing device to execute the first function as a service and provide a first function response; sending second instructions to a third processor device on a third edge computing device to execute the second function as a service and provide a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.The at least one machine readable storage medium of claim 13, wherein the edge device instructions further cause the processor circuitry to: identify, based on the first service execution request, a third function as a service; and execute the third function as a service at the first processor device at the first edge computing device and return a third function response; wherein the result of the service request is further based on the third function response.The at least one machine readable storage medium of any of claims 13-14, wherein the edge device instructions further cause the processor circuitry to: generate a first software defined network at the first processor device based on the first service execution request, the first function as a service executed on the first software defined network.The at least one machine readable storage medium of claim 15, wherein the edge device instructions further cause the processor circuitry to: access a function as a service chain from a first hard disk cache as storage in response to the first service execution request, wherein the first software defined network is generated based on the service chain.The at least one machine readable storage medium of any of claims 15-16, wherein the edge device instructions further cause the processor circuitry to: destroy the first software defined network in response to a first execution of the first function as a service.The at least one machine readable storage medium of any of claims 15-17, wherein the edge device instructions further cause the processor circuitry to: receive a second compute request upon completion of the first service execution request; wherein the second compute request comprises a request to execute the first function-as-a service and the second function-as-a service; authenticate a first security of the first software defined network; and execute, in response to the authenticate, the first security of the first software defined network, the first function as a service (function-as-a service).A method for secure and attestable function as a service, the method comprising: receiving a first service execution request on a first edge computing device, the first edge computing device comprising a first processor device and a first memory; identifying, based on the first service execution request, a first function as a service and a second function as a service; sending first function instructions to a second processor device on a second edge computing device to execute the first function as a service and return a first function response; sending second function instructions to a third processor device on a third edge computing device to execute the second function as a service and provide a second function response; and returning a service request result of the first service execution request based on the first function response and the second function response.The method of claim 19, further comprising: identifying, based on the first service execution request, a third function as a service; and executing, at the first processor device, the third function as a service at the first edge computing device and returning a third function response; wherein the result of the service request is further based on the third function response.The method of any of claims 19-20, further comprising: generating a first software-defined network at the first processor device based on the first service execution request, the first function as a service, executing on the first software-defined network.The method of claim 21, further comprising: reading into a function as a service chain from a first disk cache as storage in response to the first service execution request; wherein the first software defined network is generated based on the service chain.The method of any of claims 21-22, further comprising: receiving a second compute request upon completion of the first service execution request; wherein the second compute request comprises a request to execute the first function-as-a service and the second function-as-a service; assaying a first security of the first software-defined network; and executing, in response to the assaying, the first security of the first software-defined network, the first function as a service (function-as-a service).The method of any of claims 19-23, wherein: the first function as a service generates a first intermediate result that is executed on the first edge computing device; the second function as a service generates a second intermediate result based on the first intermediate result; and the result of the service request is generated based on the second intermediate result.The method of claim 24, further comprising: reading a first security context on the first processor device; and creating a first secure network connection between the first edge computing device and the second edge computing device based on the first security context; wherein the first intermediate result is sent over the first secure network connection.

Images