Configurable Edge Device Platform

Abstract

The techniques discussed herein relate to providing configurable edge devices. In some embodiments, a user request specifying a set of services to be executed on a cloud computing edge device may be received by a computing device operated by a cloud computing provider. A manifest may be generated according to the user request. The manifest may specify a configuration for the cloud computing edge device. Another request may be received specifying the same or a different set of services to be executed on another edge device. Another manifest specifying the configuration for the edge device may be generated and then used to provision the requested set of services on the device. In this manner, the manifest may be used to configure the platform to be utilized on any given edge device.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. patent application Ser. No. 17 / 531,632, filed November 19, 2021, entitled "Composable Edge Device Platforms," ​​and U.S. provisional patent application Ser. No. 63 / 173,244, filed April 9, 2021, entitled "Cloud Computing Edge Computing Device (Rover)," the disclosures of which are incorporated herein by reference for all purposes.

[0002] Technical Field The present disclosure relates generally to edge device platforms and, more particularly, to configuring these platforms with corresponding manifests that specify the configuration of the devices. [Background technology]

[0003] background In cloud computing, processing and storage are typically performed by one or more service providers implemented at a centralized location. Data can be received from customers at the centralized location, processed there, and then the processed (or other) data can be transmitted back to the customer. However, having a centralized location for cloud infrastructure components may not be ideal in various scenarios. For example, a traditional centralized system is not ideal when there are hundreds or thousands of Internet of Things (IoT) devices transmitting data to a central server, especially when those IoT devices are not geographically close to the cloud infrastructure computing devices. These IoT devices are considered to be at the "edge," meaning they are not close to the central server. Summary of the Invention [Problem to be solved by the invention]

[0004] Furthermore, a centralized location for cloud components may not be ideal. For example, data may be collected (e.g., by IoT devices) in disconnected areas or in places without Internet connectivity (e.g., remote locations). Current centralized cloud computing environments may not be able to meet time-sensitivity requirements when streaming data due to the inherent latency of wide-area network connections. Remotely generated data may need to be processed more quickly (e.g., to detect anomalies) than traditional centralized cloud computing systems allow. Thus, managing traditional cloud computing environments that rely on centralized components presents challenges. For example, a centralized workflow manager may not be optimal for managing workflows on geographically dispersed devices. [Means for solving the problem]

[0005] A brief overview Techniques (e.g., methods, systems, non-transitory computer-readable media having stored thereon code or instructions executable by one or more processors) for configuring various platforms, such as cloud infrastructure edge computing devices (e.g., computing devices configured to provide computing and storage at remote locations separated from centralized data centers and without public / private network connectivity), are provided. In some embodiments, configuring these platforms may utilize a corresponding manifest that specifies the configuration for the device. Various embodiments are described herein, including methods, systems, and non-transitory computer-readable media having stored thereon programs, code, or instructions executable by one or more processors.

[0006] One embodiment relates to a method for configuring a platform for cloud infrastructure edge computing devices (sometimes simply referred to as edge devices). The method may include receiving, from a computing device operated by a cloud computing provider, a first user request including a first manifest specifying a first set of services to be executed on a first cloud computing edge device. In some embodiments, the cloud computing edge device may be a device configured to selectively execute within an isolated computing environment while executing within the isolated computing environment without access to a public network. The method may further include obtaining a first set of container images corresponding to the first set of services to be executed on the first cloud computing edge device. The method may further include provisioning the first cloud computing edge device with a container including the first set of container images in accordance with the first user request. The method may further include receiving a second user request including a second manifest specifying a second set of services to be executed on a second cloud computing edge device. The method may further include obtaining, from memory, a second set of container images corresponding to the second set of services to be executed on the second cloud computing edge device. The method may further include provisioning a second set of containers, including the second set of container images, at the second cloud computing edge device in accordance with the second user request. In some embodiments, the second cloud computing edge device may be provisioned with the same or different services as the services provisioned at the first cloud computing edge device.

[0007] In some embodiments, a computing device is disclosed, which may be configured with one or more processors and one or more memories configured with executable instructions that, when executed by the one or more processors, cause the computing device to perform the method disclosed in the preceding paragraph.

[0008] Some embodiments disclose a non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by one or more processors of a computing device, cause the computing device to perform the methods disclosed herein. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary high-level architecture for a cloud infrastructure edge computing device, according to at least one embodiment. [Figure 2] FIG. 1 is a block diagram illustrating an exemplary architecture for connecting user computing devices to a cloud infrastructure edge computing device, according to at least one embodiment. [Figure 3] FIG. 1 is a block diagram illustrating an exemplary housing for a cloud infrastructure edge computing device according to at least one embodiment. [Figure 4] FIG. 1 is an exploded view of a cloud infrastructure edge computing device described herein according to at least one embodiment. [Figure 5] FIG. 1 is a block diagram illustrating an exemplary computer architecture of a cloud infrastructure edge computing device according to at least one embodiment. [Figure 6] FIG. 1 is a block diagram illustrating a distributed computing cluster including one or more edge computing devices, according to at least one embodiment. [Figure 7]FIG. 1 is a block diagram illustrating a control plane and flow for executing workflows by one or more components of a cloud infrastructure edge computing device, according to at least one embodiment. [Figure 8] FIG. 2 is a block diagram illustrating a flow for generating a manifest from a user request, according to at least one embodiment. [Figure 9] FIG. 2 is a block diagram illustrating an example manifest, according to at least one embodiment. [Figure 10] FIG. 10 is a block diagram illustrating another flow for generating a manifest from a user request, according to at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating an architecture and flow for provisioning one or more data plane resources at an edge computing device, according to at least one embodiment. [Figure 12] FIG. 1 is a block diagram illustrating an example method for provisioning different edge devices according to different manifests, according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Detailed Description In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the described embodiments.

[0011] Introduction In some examples, cloud-integrated edge services (e.g., implemented in edge computing devices) may be essential to address the desire to run time-sensitive cloud infrastructure applications outside of a centralized data center (e.g., a cloud infrastructure service provider's data center). Such edge computing devices may provide computing and storage at the edge and / or in disconnected locations (e.g., remote locations isolated from a centralized data center and lacking public / private network connectivity (e.g., internet connectivity, VPN connectivity, dedicated connectivity, etc.)), enabling low-latency processing at or near the point of data generation and ingestion. In some cases, fleets of portable (possibly ruggedized for protection) server nodes (e.g., fleets of edge devices) may be configured to physically provide cloud infrastructure services in remote locations where cloud technology has been considered technically infeasible or too costly to implement.

[0012] To a customer (e.g., a user), an edge computing device can act as an extension of the cloud infrastructure, including virtual machines (VMs), containers, functions, and data files; block volume or object store services can be delivered largely unchanged from a cloud infrastructure tenancy (e.g., a tenancy in a centralized cloud computing environment); the customer's experience may remain unchanged from the centralized cloud computing experience. Furthermore, an edge computing device may be configured to implement both a control plane and a data plane that are part of the cloud infrastructure service provider. The data plane may be configured to manage data storage, migration, processing, etc., while the control plane may be configured to control various services and architectural components of the computing device. Once the edge computing device is appropriately connected to the customer's computing device (e.g., via a local area network (LAN)), the customer may consume IaaS services (or at least a subset thereof) using the same SDKs and APIs used by the centralized cloud services.

[0013] Edge computing devices can be provided to customers in a pre-configured form so that the only action that may be required of the customer is to connect the nodes to a network (e.g., a local / on-premise network accessible by the user computing device) and power them on and / or log in. The devices can be pre-configured in various ways based on the customer's preferences / requests or can be in one of various configurations (storage-centric, compute-centric, etc.). The nodes or clusters of nodes are intended to be portable and moveable; that is, once moved and set up again (or used while moving), the deployment continues to run where it left off (or continuously). Edge computing devices can also monitor the availability of a wide area network (WAN) connection (e.g., the Internet) and, once connected to a WAN, can synchronize customer and management data with the cloud.

[0014] Potential use cases for edge computing devices include storage and processing, compute- and input / output (I / O)-intensive applications, machine learning, remote computing, low-latency databases and analytics, and data collection and migration. More specifically, edge devices can be used to store and process large volumes of image, video, audio, and IoT sensor data generated in environments where WAN connectivity is potential or unavailable (e.g., remote locations, offshore oil platforms). Once preprocessed, filtered, compressed, and / or protected, this data can be transported or forwarded to a cloud service provider, where it can be further processed by a centralized server (e.g., a traditional cloud service provider). The devices can also be used in compute- and I / O-intensive applications where low latency is paramount, such as tactical reconnaissance or 5G communications. They can also be used for machine learning, where cloud-trained models run in disconnected locations to improve efficiency, intelligence, and / or productivity in manufacturing, document management, transportation, oil and gas extraction, and / or telecommunications. They can also be used for remote computing requiring high levels of security and data privacy. Additionally, the device can be used for low-latency database and analytics workloads, with more applications optimized over time. Additionally, the device can also be used for data collection and migration of large sets of object and database management system (DBMS) data to cloud service providers, for example, at a faster and lower cost than WAN transfers.

[0015] Edge devices can natively support a distributed cloud paradigm, separating complex, multi-step compute workflows into individual components that can be deployed on the edge device's infrastructure, on-premises, and / or in the cloud. An example of such a distributed workflow is illustrated in the following scenario: An edge computing node (e.g., a disconnected edge computing device) deployed on an aircraft (e.g., a military jet) conducting a reconnaissance mission without internet access can collect large amounts of data. This data is preprocessed in near real time by a machine learning model pre-trained by the cloud service provider that provided the edge device. Even the first pass through the data with the model can detect significant anomalies and immediately alert personnel (e.g., a bridge may be destroyed and troops need to be diverted). Once the aircraft lands, the edge computing device can be physically connected to a network (e.g., an edge station potentially deployed on the runway). The preprocessed, filtered, smaller dataset can be loaded onto a cluster of edge computing device nodes at the edge station for final processing. The original edge computing device is then released and can be loaded onto another (or the same) aircraft, for example, to support the next mission. Once processing is complete at the edge station, 3D map updates are published and made available for immediate use. Change sets are then uploaded by the edge station cluster to the data center and can be used to build future models that provide intelligent tactical predictions for reconnaissance activities and more.

[0016] It should be understood that the following technologies may be employed in a variety of contexts such as telecommunications, oil and gas, healthcare, hospitality, agriculture, transportation, and logistics.

[0017] The embodiments described herein, individually and collectively, address these and other problems. Specifically, embodiments of the present disclosure provide a cloud infrastructure edge computing device.

[0018] Edge Device Architecture Edge computing devices (sometimes referred to as "cloud computing edge devices," "cloud infrastructure edge computing devices," or simply "edge devices") extend a user's centralized cloud computing tenancy by physically placing the customer's infrastructure and platform services where data is generated: at the edge, on-premise, or completely disconnected. Each deployment is created to address a customer's specific needs by provisioning VM instance images and data from the customer's centralized cloud tenancy. These workloads can function fully offline, as edge devices adapt to connectivity, operate in harsh environmental conditions, and are ready to sync with the cloud whenever connectivity is re-established.

[0019] 1 is a block diagram illustrating an exemplary high-level architecture for a cloud infrastructure edge computing device (e.g., edge device 100) according to at least one embodiment. An overview of the software and hardware components of edge device 100 is provided below.

[0020] In some examples, edge device 100 may include a containerization engine 102 (e.g., Docker, Kubernetes, etc.) configured to implement one or more containers (e.g., corresponding to container(s) 104A, 104B, 104C, through 104N, collectively referred to as “container(s) 104”). The containerization engine (e.g., containerization engine 102) may be a container orchestration system for automating the deployment, scaling, and management of computer applications. In some embodiments, the containerization engine may be configured to provide OS-level virtualization to deliver software in packages called containers. These containers are isolated from each other, can utilize their own software, libraries, and configuration files, and can communicate with each other via well-defined channels. In some embodiments, service(s) 104 may include any suitable number of services (e.g., one or more). These services may implement at least a portion of a centralized cloud function. Each service may be standalone or may operate as a distributed cluster. The edge device 100 may further include a hypervisor 106 configured to implement one or more virtual machines (e.g., virtual machines 108A, 108B, 108C-108N, collectively referred to as "virtual machine(s) 108" or "VMs 108").

[0021] In some examples, edge device 100 includes storage 110 (e.g., object storage and / or block storage for storing local data). Edge device 100 includes an operating system (OS) 112. In some embodiments, OS 112 may be optimized and / or specialized for running on edge devices. OS 112 may be configured to manage the hardware of edge device 100 and support the data plane of services running on edge device 100. OS 112 may be configured to support a particular deployment type (e.g., a single edge device deployment or a particular edge device cluster configuration). OS 112 may be configured to secure the edge device by prohibiting or otherwise blocking direct access by customers.

[0022] In some embodiments, edge device 100 may include any suitable number of central processing units (CPUs) and / or hardware such as storage drives. For example, edge device 100 shown in FIG. 1 may include one, two, or more CPUs with various numbers of cores per processor and any number of storage drives (e.g., 6.4 terabyte (TB) drives, etc.). As a non-limiting example, edge device 100 may include block and / or object storage of any suitable size. Edge device 100 may include any suitable number of central processing units (CPUs), graphics processing units (GPUs), random access memory (RAM) of any suitable size, one or more ports (e.g., QSFP28, RJ45, dual port, etc.), tamper-evident seals, or any suitable combination of the above components.

[0023] In some examples, basic system functions / services can be accessed via a RESTful API with a custom load of Linux-based software. The virtual machine(s) 108 may individually be a kernel-based virtual machine (KVM) (e.g., a virtual machine managed by a virtualization module in the Linux kernel that allows the kernel to function as a hypervisor) and / or a hardware-based virtual machine (e.g., a virtual machine managed by a virtualizer such as Quick EMUlator (QEMU), which can perform hardware virtualization that allows a virtual machine to emulate multiple hardware architectures). Storage 110 is represented as a component separate from service(s) 104 and VM(s) 108, but can run as a container (e.g., container 104A) or within a VM (e.g., VM 108A). In some examples, it may be preferable to implement storage 110 (e.g., object storage, block storage, etc.) as a container.

[0024] 2 illustrates an example architecture 200 for connecting an edge device described herein (e.g., edge device 100 of FIG. 1 ) to a computing device 202 (e.g., a user computing device). Computing device 202 may be any type of computing device, including, but not limited to, a laptop computer, a desktop computer, etc. Edge device 204 (an example of edge device 100 of FIG. 1 ) may include a containerization engine 206 (an example of containerization engine 102 of FIG. 1 ), a hypervisor 208 (an example of one hypervisor 106), and storage 210 (an example of one storage 110).

[0025] Additionally, as briefly described above, the edge device 100 may include an API proxy 212 for managing RESTful API calls received from the computing device 202. The API calls may enter the edge device 204 via a network interface card (NIC) 214 internal to the edge device 204. The NIC 214 may be used to connect the edge device 204 to the computing device 202 via a local area network (e.g., LAN 216). API calls received by the NIC 214 may be sent to an exposed endpoint (e.g., endpoint 218), which may implement a web server. The web server can send the request to the API proxy 212, which can route the request to the appropriate service (e.g., the containerization engine 206, the hypervisor 208, and / or the storage 210). The exposed endpoint / web server may also be configured to implement a lightweight console (e.g., a user interface displayed on the computing device 202) for customer use.

[0026] The lightweight console can run within a web browser (e.g., Mozilla® Firefox®, etc.) on a laptop computer, desktop computer, or other network-accessible device (e.g., connected to a local area network (LAN 216)) that is network-connected (e.g., via a router, cable, etc.) to edge device 204. Edge device 204 can expose an endpoint 218 for console connections, and a web server can send data to the web browser of computing device 202 over LAN 216.

[0027] FIG. 3 illustrates an exemplary physical enclosure 300 for an edge device described herein (e.g., edge device 100 of FIG. 1 ). A variety of different form factors, shapes, colors, etc. can be employed to construct a (e.g., durable) box that can house the edge computing device. The physical enclosure can include a handle 302, as shown, and can include tamper-evident elements that would reveal if someone were to crack open the enclosure. In this way, a service provider offering an edge computing device can ensure that the device has not been tampered with. In some instances, the physical enclosure 300 may be impossible to open. However, in some cases, it may be possible, but extreme measures are required.

[0028] FIG. 4 is an exploded view of a cloud infrastructure edge computing device described herein (e.g., edge device 400, which is an example of edge device 100 of FIG. 1 ) according to at least one embodiment. The various components described with respect to FIGS. 1 and 2 may be communicatively mounted on one or more motherboards and / or interface cards within edge device 400. The illustrated configuration of components is merely one implementation. The specific locations of the components illustrated are not intended to be limiting, and as previously mentioned, any configuration capable of achieving the functionality described herein is acceptable. Once the components are installed, the entire box can be closed, sealed, and locked with tamper-evident components.

[0029] Edge device 400 is a single enclosure. The enclosure can be designed to house any suitable number of SAS (serially attached SCSI) solid-state drives (SSDs), as well as all other components within the enclosure (e.g., CPU, memory, GPU, etc.). The system can include one or more (e.g., 12 Gb) SAS connections to each drive within a fully enclosed sheet metal enclosure designed to fit in a standard 19-inch rack on an L-bracket / shelf, on a tabletop, or upright next to a desk using a floor stand.

[0030] The system may include a tamper-resistant housing, a front security plug with a rear security interlock feature that covers the screws that hold the front bezel in place. In some embodiments, the system may include a dual-socket motherboard and any suitable capacity of DRAM. In some embodiments, the system may include any suitable number (e.g., 2, 3, etc.) of SATA SSDs, a storage controller, a built-in network connection, one or more ports (e.g., dual port, serial port, etc.), one or more fans as part of a cooling system, or any suitable combination of the above.

[0031] As a non-limiting example, edge device 400 may be constructed with an external extruded aluminum case secured in front with a vented bezel and a rear panel that exposes only the I / O connections necessary for data transfer and management. Mounting can be designed to accommodate any suitable motherboard, fan, and power supply.

[0032] FIG. 5 is a block diagram illustrating an exemplary computer architecture for a cloud infrastructure edge computing device (e.g., edge device 500, which is an example of edge devices 100 and 204 of FIGS. 1 and 2, respectively) according to at least one embodiment. Edge device 500 can be thought of as a cloud integration service that extends some or all of traditional cloud functionality to locations where cloud data centers may not be accessible or may not be accessible. This can be achieved through portable, durable server nodes that provide cloud-like functionality in locations without WAN connectivity. This allows customers to shift select cloud workloads to remote locations, enabling intensive data processing operations closer to data ingestion points at the edge of the cloud infrastructure.

[0033] The edge device 500 may include any suitable number of services (e.g., service(s) 502). Each service may run as a container (e.g., a Docker container) locally on the edge device 500. The service(s) 502 may be communicatively connected via a substrate network 504 so that communications between services are encrypted (e.g., according to a security protocol such as MACsec). Each container may be assigned a substrate IP address (e.g., a static address) to which traffic can be addressed. In some embodiments, the security protocol (e.g., MACsec) is configured at provisioning time (e.g., before the edge device 500 is shipped to a user). The edge device's system software (including service(s) 502) may run in a secure environment protected by boot security software (e.g., Trenchboot Secure Launch). Users may be restricted from accessing the secure environment and / or the substrate network 504. To minimize the amount of resources used by these services, service code may be compiled and stored on disk to reduce RAM space as well as reduce CPU load on the edge device 500.

[0034] Some example services included in the service(s) 502 are a UI console service, an identity control plane (CP) service, an identity data plane (DP) service, a compute application programming interface (API) service, a compute worker thread service, a virtual network (VN) API service, a block storage API service, a function-as-a-service service, an event service, an object storage management service (e.g., implementing a storage platform such as Ceph Storage), a compute DP service (e.g., the example hypervisor 208 in FIG. 2 ), a VN DP service, a block storage management service, a function-as-a-service API service, a function-as-a-service load balancing (LB) service, a function-as-a-service process thread service, a distributed data store management service (e.g., etcd3), a dynamic host configuration protocol service, a domain name system service, a network time protocol (NTP) service, etc. Some example functionality provided by these services are described below.

[0035] As an example, the Compute DP service may be configured (e.g., pre-configured and provisioned on the edge device 500) to isolate VM(s) 508 on the same hypervisor host. The Compute DP service may utilize any suitable container engine (e.g., Docker containers, MicroContainers, etc.) to isolate VM(s) 508 from each other on the same hypervisor host. The Compute DP service may utilize any suitable hypervisor (e.g., Quick EMUlator (QEMU), Kernel-based Virtual Machine (KVM), etc.) to provide virtual hardware emulation for the VM(s) 508. In some embodiments, the VNIC(s) 506 are connected to any suitable number of virtual networks (e.g., subnets of private virtual network(s) (PVN(s)) 505) and are assigned private Internet Protocol (IP) addresses. A VM may have multiple VNICs from different VCNs and different subnets. The maximum number of VNICs can be limited by a predefined threshold (e.g., configuration data called a “VM shape” that defines, for example, the number of VNICs per VM). In some embodiments, the predefined threshold applies to each of the VM(s) 508. The subnets utilized by the VNIC(s) 506 can be separated by VLANs. In some embodiments, some or all of the VNIC(s) 506 may be assigned public and / or private IP addresses. The public IP addresses are addresses within the network 520, and the private IP addresses refer to the IP addresses of the PVN(s) 505.

[0036] In some embodiments, the edge device 500 enables various network functions through a number of services, such as a network address translation (NAT) service, a dynamic host configuration protocol (DHCP) service, a domain name system (DNS) service, a network time protocol (NTP) service, a metadata service, and a public API service. The metadata service may provide initialization data and other metadata to all the VM(s) 508. In some embodiments, the DHCP service assigns a private IP address to each of the VNIC(s) 506, and each of the VM(s) 508 has one or more VNICs. The DNS service may provide domain name resolution to the VM(s) 508 on the edge device 500. The NTP may provide time synchronization to the VM(s) 508. In some embodiments, a public IP service running as part of the service(s) 502 may enable a VM to access the public API without assigning a public IP to the VM and without configuring a service gateway.

[0037] In some embodiments, at least one of the VM(s) 508 may implement block (or object) storage. In some embodiments, a hypervisor associated with a virtual machine may include a library that enables the hypervisor to use a distributed data storage platform (e.g., Ceph). The library may utilize a protocol associated with the storage platform (e.g., RADOS Block Device (RBD)) to facilitate storing block-based data. The distributed data storage platform may be implemented on multiple virtual machines. In some embodiments, the distributed data storage platform supports creating snapshots and copying block volumes. VM images and VM block volumes may be Ceph block devices. In some embodiments, the VM(s) implementing the distributed data storage platform use system reserved resources (e.g., 8 CPU cores or any subset of the total number of CPUs available on the edge device 500). For example, to provision a boot volume, a block device image may be copied to the boot volume of the block device. The distributed data storage platform may use a block device that includes multiple nodes for redundancy. If some nodes fail, the block device can continue to operate. In some embodiments, a distributed data storage platform (e.g., Ceph, etc.) automatically recovers block device data in the event of a minority node failure. Block storage may be utilized to store images of any suitable deployable resource. As an example, an image may be utilized to launch a VM. In some embodiments, an image may correspond to a particular VM shape (e.g., a compute-heavy VM, a GPU-optimized VM, a storage VM, etc.).

[0038] The Compute API service may support operations such as 1) starting and stopping VMs, 2) stopping, starting, and restarting VMs, 3) getting a list of VMs and / or information about a specific VM, 4) getting a VM console history API, 5) taking a VM snapshot, and 6) attaching / detaching a block volume. In some embodiments, the Compute API service can be used to invoke other services (e.g., a Compute DP service, an Identity DP service for authentication and authorization, etc.).

[0039] Some of the functionality of the other services is described in connection with FIG. 7 . In general, while each service may not be described in detail herein, the general functionality provided by the service(s) 502 may include functionality of cloud services provided by a remote cloud service provider. In some embodiments, the edge device 500 may be associated with predefined regions and / or realms so that some of the service(s) 502 can operate as if they were running in a cloud computing environment, regardless of whether they are running on one or more local devices (one or more edge devices) as single instances or as part of a distributed service that may not have, or may have intermittent, public network access to the cloud computing environment associated with a customer. A “region” refers to a geographic location where a service center resides. A “realm” refers to a logical collection of regions. Realms may be isolated from each other and may not share data.

[0040] In some embodiments, the edge device 500 may provide any suitable number of virtual networks (e.g., PVNs 505) using computational, memory, and networking resources (e.g., virtual network interface card(s) (VNIC(s) 506)). A virtual network is a logical network running on top of a physical substrate network. The service(s) 502 may be used to deploy one or more customer resources or workloads, such as virtual machines (e.g., virtual machine(s) (VM(s) 508 running compute instances), on these private virtual networks. Any suitable combination of the VM(s) 508 may run functions (e.g., compute instances, storage, etc.) that are individually accessible through a virtual NIC (e.g., one of the virtual NIC(s) 506). Each VM that is part of a PVN is associated with a VNIC that enables the VM (e.g., compute instance) to be a member of a subnet of the PVN. The VNIC associated with a VM facilitates communication of packets or frames to and from the VM. A VNIC may be associated with a VM when the VM is created. The PVN(s) 505 can take many forms, such as a peer-to-peer network, an IP network, etc. In some embodiments, the substrate network traffic of the service(s) 502 may be encrypted and / or isolated (e.g., by a different PVN or subnet) from the network traffic of one or more VM(s) 508 running on the edge device 500.

[0041] In this manner, edge device 500 provides infrastructure and a set of complementary services that enable customers to build and run a wide range of applications (e.g., compute instances), services, and / or storage in a highly available, physically local, virtually hosted environment. Customers do not manage or control the underlying physical resources provided by edge device 500, but rather control the scaling of virtual machines (e.g., compute instances, virtual NICs, block or object storage, etc.), the deployment of applications to those virtual machines, etc. All workloads on edge device 500 may be divided into different CPU sets (e.g., VM and non-VM). One set (e.g., non-VM, such as workloads executed by service(s) 502) utilizes a subset of edge device 500's CPU cores (e.g., 8), and the other set (e.g., VM workloads executed by VM(s)).

[0042] The edge device 500 may be communicatively connected to a user device (e.g., computing device 202 of FIG. 2 ) via one or more network interfaces (e.g., NIC2 and / or NIC4) and a network 520 to interact with and / or manage the VM(s) 508. In particular embodiments, a lightweight console may be provided at the user device via a web-based user interface that can be used to access and manage the edge device 500. In some implementations, the console is a web-based application (e.g., one of the services 502) provided by the edge device 500.

[0043] 5 shows a single edge device, however, it should be understood that two or more edge devices may be utilized as a distributed computing cluster.

[0044] FIG. 6 is a block diagram illustrating a distributed computing cluster 600 including one or more edge computing devices (e.g., edge devices 602 and 604, each of which is an example of edge device 500 of FIG. 5), according to at least one embodiment.

[0045] Each edge device of distributed computing cluster 600 may be connected via substrate network 606 (an example of substrate network 504 in FIG. 5 ). In some embodiments, edge devices (sometimes referred to as “edge computing nodes” or “edge nodes”) of distributed computing cluster 600 may be connected by substrate network 606 using one or more switches (e.g., switches 608 and / or 610). In some embodiments, NIC1 and NIC5 may include a particular connector (e.g., an RJ45 connector), and NIC3 and NIC8 may include the same or a different connector (e.g., a QSFP28 100GbE connector). In some embodiments, only one edge device of distributed computing cluster 600 is connected to a customer network, such as network(s) 620 (an example of network 520 in FIG. 5 ). Thus, not only may traffic between services of an edge device be encrypted and isolated from other traffic of a given edge device, but traffic between distributed services operating across multiple edge devices may also be encrypted and isolated from other traffic of the computing cluster. In some embodiments, each edge device is pre-configured as a specific node of distributed computing cluster 600. In other embodiments, a user can configure the number and topology of edge devices in the distributed computing cluster 600.

[0046] FIG. 7 is a block diagram illustrating a flow 700 for executing a workflow by one or more components of a cloud infrastructure edge computing device, according to at least one embodiment. The components executing flow 700 may include an API service 702, a database (DB) 704, a service 706, a hypervisor service 708, a PVN CP service, and a block storage CP service 714, although more or fewer services may be included. In some embodiments, each service in FIG. 7 is an example of a service from the service(s) 502 in FIG. 5. In some embodiments, at least some of the functionality described in connection with the services in FIG. 7 may be combined in any suitable combination and provided as a single service or instance of the same service. As an example, in some embodiments, the functionality of services 702-708 may be provided by a single service (e.g., the Compute CP service described above in connection with FIG. 5). In some embodiments, the functionality provided by services 702-708 may be provided by a single edge device (e.g., edge device 500 of FIG. 5) or by two or more edge devices (e.g., edge device 602 and edge device 604 of FIG. 6).

[0047] In some embodiments, API services 702 may be configured to accept work requests that include intended state data that describes the intended state of a set of data plane resources (e.g., VM(s) 508 of FIG. 5 ). As a non-limiting example, a user 720 may utilize a user device (e.g., user device 202 of FIG. 2 ) to access a user interface that allows the user to make various selections indicating a desire to launch a VM. User input may be received by API services 702 (an example of the compute CP service of FIG. 5 ), which may utilize a predefined Launch VM API to generate a work request (WR) (e.g., WR 722) and store the work request in a distributed database (e.g., DB 704). In some embodiments, DB 704 may be a computing cluster configured to use etcd3 as an immediately consistent, highly available, transactional distributed database. Generally, a work request indicates the desire and information needed to create and / or modify data plane resources, such as VM(s) 508. In some embodiments, the work request includes state information that indicates the desired state of the data plane resources. In some embodiments, DB704 may be accessible to all services running on any edge device (and by services running on any suitable edge device of an edge device cluster, such as distributed computing cluster 600).

[0048] Service 706 (e.g., an example of the Compute CP service of FIG. 5) may be configured to execute one or more worker processes (e.g., one or more computing threads, such as computing thread 710). Some of these worker processes may be configured by service 706 at any appropriate time to execute sequential and / or continuous predefined workflows. As an example, service 706 may configure one or more worker threads (e.g., including computing thread 710) to monitor DB 704 for new work requests (e.g., WR 722). The computing threads may be configured to determine whether work request WR 722 has already been attended. In some embodiments, this involves checking a predefined storage bucket in DB 704 for a unique identifier associated with WR 722. If the unique ID contained in WR722 does not appear in the bucket (or if the WR is otherwise indicated as not being picked up for processing), computing thread 710 (e.g., a nanny thread) may initialize a workflow thread (e.g., another instance of computing thread 710), which may then be configured by computing thread 710 to execute a workflow corresponding to launching a VM corresponding to WR722.

[0049] The initialized workflow thread may be communicatively coupled to a workflow service (not shown) (e.g., via substrate network 504 of FIG. 5 ). The workflow service may be configured to identify a predefined workflow corresponding to launching a VM, and thus WR722, from one or more predefined workflows. These predefined workflows identify one or more steps / actions to be performed, and a sequence for those steps, to achieve a predefined goal (e.g., start a virtual machine, stop / start a virtual machine, terminate a virtual machine, create a block volume, delete a block volume, etc.). The workflow thread may launch the VM workflow and oversee its execution by various other entities. In some embodiments, the workflow thread may pass any appropriate portion of the DP resource's intended state data to any appropriate combination of services.

[0050] As a non-limiting example, as part of a workflow for launching a virtual machine (e.g., a VM hosted by hypervisor service 708), one or more APIs may be invoked to create and add a VNIC. Similarly, numerous APIs may be provided for creating and / or adding block storage volume APIs. In some embodiments, a workflow thread may perform any appropriate call to one or more APIs to invoke the functionality of PVN CP service 712, which may be configured to create and add a VNIC. The workflow thread then invokes block storage CP service 714, which may perform any appropriate operation to create and add a block storage volume. A worker thread overseeing the workflow may ensure a specified order (e.g., creating a VNIC first before creating a block volume). This worker thread may be configured to catch errors and / or exceptions from the one or more services it invokes. If no exceptions / errors occur, the worker thread overseeing the workflow may provide the appropriate data to hypervisor service 708 (via the underlay network), and hypervisor service 708 performs the function to create the requested VM. Hypervisor services 708 may provide actual state data for the newly launched VM. In some embodiments, a worker thread overseeing the workflow may store the actual state data in DB 704 for later reference (e.g., when a monitor may determine whether the actual state data matches the requested state data, indicating no changes are needed, or whether the actual state data does not match the requested state data, indicating changes to data plane resources are needed).

[0051] In some embodiments, the workflow thread may be communicatively coupled to a cluster manager (not shown). The cluster manager may be configured to manage any suitable number of computing clusters. In some embodiments, the cluster manager may be configured to manage any suitable type of computing cluster (e.g., a Kubernetes cluster, a set of computing nodes used to run containerized applications, etc.). The workflow thread may be configured to perform any suitable operation to cause the cluster manager to perform any suitable orchestration operation on the DP resource(s) (e.g., VMs) according to the specified instructions to align the DP resource(s) with the intended state data. In some embodiments, a monitoring entity (e.g., the workflow thread, a thread launched by the workflow thread) may be communicatively coupled to the DP resource(s) 116 and configured to monitor the health of the DP resource(s). In some embodiments, the monitoring entity may be configured to store any suitable health data in DB 704.

[0052] 7 are exemplary in nature and are not intended to limit the scope of the present disclosure. The specific operations performed and services utilized may vary depending on the particular workflow associated with the requested operation.

[0053] FIG. 8 is a block diagram illustrating a flow 800 for generating a manifest from a user request, according to at least one embodiment. FIG. 8 illustrates a service provider computer (e.g., service provider computer 802). The service provider computer 802 can be operated by or on behalf of a cloud computing provider. In some embodiments, the service provider computer of FIG. 8 implements a cloud computing service for generating a manifest that can configure one or more edge devices. The service provider computer of FIG. 8 can be communicatively connected to or operated as part of a cloud computing environment operated by a cloud computing provider. The user device 804 can be any suitable electronic device (e.g., laptop, desktop, smartphone, etc.) and can be communicatively connected to the service provider computer 802 via a network (e.g., a public network or a private network). The service provider computer 802 can be configured to host one or more interfaces through which user input can be provided. These user interfaces can be associated with one or more configured edge devices.

[0054] Flow 800 may begin at 810, where the service provider computer 802 exposes one or more user interfaces through which user input can be obtained. In some embodiments, these user interfaces allow a user to select various services and / or data plane resources to be configured on one or more edge devices (edge ​​device 806 is one example). As an example, these interfaces may be used to define a configuration (e.g., a particular set of services, a particular number and / or type of virtual machines, or any suitable attribute of edge device 806). In some embodiments, a user may define a cluster of edge devices and their corresponding configurations. Thus, through these interfaces, a user may indicate that edge device 806 is compute-intensive (e.g., a majority of the virtual machines running on edge device 806 provide computing resources), storage-intensive (e.g., a majority of the virtual machines running on edge device 806 provide storage resources), GPU-intensive (e.g., a majority of the virtual machines running on edge device 806 provide GPU resources), etc. (e.g., based at least in part on the number of virtual machines requested and the particular configuration of those virtual machines selected by the user). The user interface may be in any suitable form that allows a user to select and / or define these attributes for one or more edge devices (eg, edge device 806).

[0055] At 812, the user device 804 may submit user input in a user request received by the service provider computer 802. The service provider computer 802 may host a build service within a cloud computing environment.

[0056] At 814, the service provider computer 802 may generate a manifest 815 (e.g., a record, a file, etc.) corresponding to the user request. Once completed, the manifest 815 may be utilized to configure edge devices according to the user request. In some embodiments, the service provider computer 802 may generate the manifest 815 based at least in part on a predefined template. In some embodiments, the manifest 815 may be in any suitable format (e.g., JSON, XML, etc.). Once generated, the service provider computer 802 may begin modifying the manifest 815 to correspond to the user request. As an example, the manifest 815 may be modified to include configuration information for one or more edge devices.

[0057] 9 is a block diagram illustrating an example manifest 900 (an example of manifest 815 of FIG. 8 ) according to at least one embodiment. Manifest 900 includes sections 902 and 904. Section 902 corresponds to one edge device and section 904 corresponds to another edge device. Manifest 900 may define a configuration of multiple edge devices operating as a cluster. In some embodiments, manifest 900 may define a cluster identifier in 902. Any suitable number of nodes may be provided in section 904. In some embodiments, nodes may be assigned names, as shown at 906. Manifest 900 may indicate a set of device attributes for a given node (e.g., a particular edge device) in 908.

[0058] The manifest may include any suitable information related to one or more network interface cards. A network interface card may be defined as having a media access control (MAC) address or other suitable identifier, such as a name. In some embodiments, the manifest 900 may identify a driver for the network interface card in section 910. Section 910 may include any suitable number of NIC definitions.

[0059] The manifest may identify any suitable number of services. Manifest 900 shows at least one service. Various service-level attributes may be identified within the manifest. As an example, section 912 may include the name of the service, where an image for the service can be found, the default network name on which the service operates, an indicator of whether the service starts at boot time, and the IP address of the service. Manifest 900 may include any suitable number of services within section 912.

[0060] Although manifest 900 is shown as including particular attributes of a cluster, node, or device, it should be understood that the manifest may identify any suitable attributes of a cluster, node, or device. Thus, the example attributes shown in Figure 9 are not intended to be considered an exhaustive list of attributes that may be included in any given manifest.

[0061] Returning to FIG. 8 , at 816, the service provider computer 802 may perform any suitable operation to generate a list of services from the user input and collect artifacts (e.g., container images, OStree commits, etc.) corresponding to the list of services. In some embodiments, the service provider computer 802 may collect these artifacts from one or more storage locations of the cloud computing environment to which the service provider computer 802 belongs. In some embodiments, some of these artifacts may include a container for each of the set of services requested for a given edge device. The service provider computer 802 may be configured to collect any suitable number of artifacts corresponding to the number of edge devices defined in the user request.

[0062] At 818, the manifest 815 may be modified to indicate configuration attributes / details of specific services operated on the edge device. As an example, each artifact collected at 816 may include an executable script that, when executed, modifies the manifest file to include entries corresponding to the service with which the artifact is associated. The service provider computer 802 may be configured to execute each script of each artifact. Each script may be configured to modify the manifest file to include configuration information corresponding to the respective service. Each script may modify the manifest to include any suitable entity definitions, which define attributes of the device or service.

[0063] At 820, the service provider computer 802 may execute a predefined rule set to assign one or more network addresses to any suitable number of devices / entities / services identified in the manifest 815. As an example, each node of a cluster (e.g., each edge device operating as a node in a cluster of edge devices) may be assigned an IP address.

[0064] At 822, the service provider computer 802 may generate an edge device (ED) image based at least in part on the artifacts collected at 818. In some embodiments, the ED image may be an uber-tarball that includes the entire container and OStree on-box repository for a given edge device.

[0065] At 824, the service provider computer 802 may be configured to collect any suitable pre-defined configuration files, credentials (e.g., API keys, data volume passwords, Macsec keys or other suitable encryption keys, etc.), agents (e.g., netboot agents), etc.

[0066] At 826, the service provider computer 802 may provision the edge device 806 by providing the ED image, manifest, configuration file, credentials, and agent to the edge device 806. It should be understood that in some embodiments, a service provider computer other than the one that created the manifest (e.g., a service provider computer located at a provisioning center) may perform the provisioning operation.

[0067] At 828, the edge device 806 may perform any appropriate operations to provision the edge device 806 according to the manifest 815. As an example, a netboot agent running on the edge device 806 may perform operations such as PXE booting, setting up partitions, dmcrypt, formatting a file system, querying a service provider computer for an artifact URL, fetching the artifact using the URL, committing the root file system to an OStree repository, loading a container into a container repository, deploying the OStree commit, fetching a remote key and installing a local key, installing Trenchboot, sealing an OS partition LUKS key (e.g., in a trusted platform module such as a chip, hardware security module, integrated circuit platform, or other hardware, firmware, and / or software to provide secure initialization of the edge device and security management of stored secrets, including cryptographic key(s)) using the customer password provided as a credential.

[0068] After the edge device(s) (edge ​​device 806 is an example) is configured, the cloud computing provider may ship or otherwise deliver the edge device(s) to the customer. The edge device(s) may be configured according to the user input provided at 812.

[0069] FIG. 10 is a block diagram illustrating another flow 1000 for generating a manifest 1002 from a user request, according to at least one embodiment. FIG. 10 illustrates a service provider computer 1004 (e.g., an example of service provider computer 802 of FIG. 8 ). Service provider computer 1004 may be operated by or on behalf of a cloud computing provider. In some embodiments, the service provider computer of FIG. 10 implements a cloud computing service for generating a manifest (e.g., manifest 1002) that can configure one or more edge devices (edge ​​devices 1006 and 1008, each an example of edge device 806 of FIG. 8 ). The service provider computer of FIG. 10 may be communicatively connected to or operate as part of a cloud computing environment operated by a cloud computing provider. User device 1010 may be any suitable electronic device (e.g., laptop, desktop, smartphone, etc.) and may be communicatively connected to service provider computer 1004 via a network (e.g., a public or private network, not shown). The service provider computer 1004 may be configured to host one or more interfaces through which user input may be provided. These user interfaces may be associated with one or more configured edge devices. In some embodiments, a user may desire to operate the distributed computing cluster 1012 using at least edge devices 1006 and 1008. Any suitable number of edge devices may be utilized in the distributed computing cluster 1012.

[0070] Flow 1000 may begin at 1014, where service provider computer 1004 exposes one or more user interfaces through which user input may be obtained (e.g., from user device 1010). In some embodiments, these user interfaces allow a user to select various services and / or data plane resources to be configured on edge devices 1006 and 1008. As an example, these interfaces may be used to define a configuration (e.g., a particular set of services, a particular number and / or type of virtual machines, or any suitable attributes of edge devices 1006 and 1008). In some embodiments, a user may want edge devices 1006 and 1008 to have the same configuration / service set. In other embodiments, a user may specify different configurations and / or service sets for each edge device (e.g., one may be compute-intensive and one storage-intensive). The user interfaces may be in any suitable format that allows a user to select and / or define these attributes of one or more edge devices (e.g., edge device 806).

[0071] At 1016, the user device 1010 may submit user input in a user request that is received by the service provider computer 1004. The service provider computer 1004 may be hosting a build service within a cloud computing environment. The build service may be configured to receive the user request.

[0072] At 1018, the service provider computer 802 may generate a manifest 1002 (e.g., a record, a file, etc.) corresponding to the user request. Once completed, the manifest 1002 may be utilized to configure the edge devices 1006 and 1008 according to the user request. In some embodiments, the service provider computer 1004 may generate the manifest 1002 based at least in part on a predefined template. As described above, the manifest 1002 may be in any suitable format (e.g., JSON, XML, etc.). Once generated, the service provider computer 1004 may begin modifying the manifest 1002 to correspond to the user request. As an example, the manifest 1002 may be modified to include configuration information for one or more edge devices.

[0073] At 1020, any suitable combination of the operations described with respect to steps 816-824 of FIG. 8 may be performed to modify the manifest 1002 according to the user request and generate an ED image based at least in part on obtaining artifacts, credentials, configuration files, agents, etc. corresponding to the services specified by the user request.

[0074] At 1026, the service provider computer 1004 may provision the edge devices 1006 and 1008 by providing the ED image, manifest, configuration file, credentials, and agent to the edge devices. It should be understood that in some embodiments, another service provider computer other than the one that created the manifest (e.g., a service provider computer located at a provisioning center) can perform provisioning operations on the edge devices (in this case, edge devices 1006 and 1008) of the distributed computing cluster 1012.

[0075] At 1028, each edge device may perform any suitable operations to provision one or more data plane resources according to manifest 1002. As an example, a netboot agent running on edge device 1006 (and / or edge device 1008) may perform operations such as PXE boot, set up partitions, dmcrypt, format the file system, query (a service provider computer) for artifact URLs, fetch the artifacts from the data store using the URLs, commit the root file system to an OStree repository, load the container into the container repository, deploy the OStree commit, fetch a remote key (e.g., a customer password to access the object store disk) and install the local key, install Trenchboot, and seal the OS partition LUKS key into the boot partition.

[0076] After the edge device(s) 1006 and 1008 are configured, the cloud computing provider may ship or otherwise deliver the edge device(s) to the customer. The edge devices may be configured to operate as a distributed computing cluster 1012 according to user input provided at 1016.

[0077] Subsequently, edge device 1008 may cease operation for some reason (e.g., a system failure occurs at 1030). At 1034, user device 1010 (or any suitable user device) can be used to request a replacement device (e.g., edge device 1032, which is an example of edge device 802 and edge devices 1006 and 1008 in FIG. 8).

[0078] At 1036, the service provider computer 802 may update the manifest 1002 to include the configuration information necessary to configure the edge device 1032 according to the user request. In some embodiments, the user request may specify that the edge device 1032 be configured as an exact replacement for the edge device 1008, with the same configuration (e.g., set of services, data plane resources, etc.), or in some embodiments, the user request may indicate that a different configuration be used.

[0079] At 1038, any suitable combination of the operations discussed with respect to steps 816-824 of FIG. 8 and the operations at 1020 may be performed to modify the manifest 1002 according to the user request and generate an ED image based at least in part on obtaining artifacts, credentials, configuration files, agents, etc. corresponding to the services specified by the user request.

[0080] At 1040, the service provider computer 1004 may provision the edge device 1032 providing the ED image, manifest, configuration file, credentials, and agent to the edge device. It should be understood that in some embodiments, a service provider computer other than the one that created the manifest (e.g., a service provider computer located at a provisioning center) may perform the provisioning operations for the edge device 1032. Once configured, the edge device 1032 may operate as part of the distributed computing cluster 1012.

[0081] Although not shown, at any appropriate time, edge device 1008 (or any edge device in distributed computing cluster 1012) may be physically returned to the service provider and reconfigured with the same and / or a different configuration than the previously provided configuration using the same or a different manifest (e.g., manifest 1002).

[0082] 11 is a block diagram illustrating an architecture 1100 and flow for provisioning one or more data plane resources at an edge computing device (an example of the edge devices of FIGS. 1-8, 10, and 11), according to at least one embodiment. The architecture 1100 may include a control plane 1102 and a data plane 1104.

[0083] In some embodiments, control plane 1102 may be responsible for accepting work requests that include intended state data that describes the intended state of a set of one or more data plane resources. For example, the work requests may be received by control plane application programming interface (API) 1106. In some embodiments, the work requests may be in the form of a manifest (e.g., manifest 1001, which is an example of a manifest generated by flow 800 of FIG. 8 or flow 1000 of FIG. 10). In some embodiments, control plane API 1106 may be an example of service(s) 502 of FIG. 5. Control plane API 1106 may be configured to receive any suitable number of work requests (e.g., manifest 1001) corresponding to one or more data resources (e.g., virtual machines, clusters of virtual machines, etc.) from user devices.

[0084] In some embodiments, the manifest 1001 may include an identifier that may uniquely identify the manifest 1001 as a work request so that the manifest 1001 can be distinguished from other work requests. The request identifier may be an alphanumeric string of any appropriate length that is unique to and capable of identifying the work request. The intended state data may include any appropriate number of parameters. These parameters may define attributes of the requested data plane resource, including, but not limited to, the resource's identifier, availability domain, shape corresponding to the node, number of processing units of the resource, amount of random access memory (RAM) of the resource, amount of disk memory, role (e.g., data node, master node, etc.), state (e.g., health), etc. In some embodiments, the control plane API 1106 may be configured to store all received work requests (e.g., manifest 1001) in a data store (e.g., control plane (CP) data store 1108, which is a distributed data store implemented by a cluster of edge devices on which the edge devices executing the components of FIG. 11 operate).

[0085] In some embodiments, the CP data store 1108 may be configured to store work requests and / or intended state data corresponding to the intended state of the data plane 1104. In some embodiments, the CP data store 1108 may be configured to store a mapping between one or more data plane identifiers (DPIDs) of the DP resource(s) 1112 and intended state data and / or current state data. The intended state data is data that specifies one or more aspects of the DP resource that are requested and for which the DP resource is intended to be modified. The current state data (sometimes referred to as "actual state data") corresponds to one or more parameters that identify one or more current aspects of the currently operating DP resource.

[0086] Control plane 1102 may include a control plane (CP) monitoring component 1110. CP monitoring component 1110 may be configured to periodically (e.g., according to a predetermined frequency, schedule, etc.) determine whether intended state data (e.g., from a previously received work request) received by control plane API 1106 and stored in CP data store 1108 matches current state data stored for the corresponding DP resource (if that DP resource currently exists). CP monitoring component 1110 may be communicatively coupled to non-compute service(s) 1114 (e.g., via substrate network 504 of FIG. 5 ), which may include any suitable number of cloud computing services configured to manage billing, identity, authorization, etc. In some embodiments, CP monitoring component 1110, in-memory workflow manager 1116, and CP worker(s) 1118 are provided by a common service (e.g., service 706 of FIG. 7 ). 5. Non-compute service(s) 1114 may be the remaining set of services of service(s) 502, excluding control plane API 1106 and services (e.g., service 706) that implement CP monitoring component 1110, in-memory workflow manager 1116, and CP worker(s) 1118. In some embodiments, CP monitoring component 1110 may be communicatively coupled to in-memory workflow manager 1116 and configured to invoke functions provided by in-memory workflow manager 1116. As an example, if CP monitoring component 1110 determines that the current state data of a DP resource is not in line with (e.g., inconsistent with) the intended state data stored in CP data store 814, it may invoke functions of in-memory workflow manager 1116 to correct the inconsistency.

[0087] In some embodiments, the in-memory workflow manager 1116 may be configured to identify one or more pre-defined workflows that each identify an operation to perform to configure the DP resource(s) 1112 according to the corresponding intended state data. In some embodiments, the in-memory workflow manager 1116 may be configured to initiate one or more workers (e.g., computational threads) of the control plane (CP) worker(s) 1118 and forward the workflow instructions and / or the intended state data to a given CP worker(s) to perform operations related to configuring the corresponding DP resource(s) according to the received intended state data. In some embodiments, the CP worker(s) 1118 may provide service-specific orchestration operations. The CP worker(s) 1118 may be communicatively coupled to any suitable number of services (e.g., non-compute service(s) 1114), including any suitable combination of compute services, storage services, etc. In some embodiments, the CP worker(s) 1118 may be configured to provide instructions to the data plane (DP) manager 1122 to configure one or more DP resources. DP manager 1122 (eg, an example of hypervisor service 708 in FIG. 7) may be configured to create, modify, and / or remove or delete any suitable DP resources.

[0088] In some embodiments, the DP manager 1122 may be configured to manage any suitable number of computing components (e.g., the DP resource(s) 1112, which collectively may be an example of a computing cluster). In some embodiments, the DP manager 1122 may be configured to manage any suitable type of computing cluster (e.g., a Kubernetes cluster, a set of computing nodes used to run containerized applications, etc.). The CP worker(s) 1118 may be configured to perform any suitable operation to cause the DP manager(s) 1122 to perform any suitable orchestration operation on the DP resource(s) 1112 according to instructions identified by the in-memory workflow manager 1116 to configure the DP resource(s) 1112 according to intended state data. In some embodiments, the CP monitoring component 1110 may be communicatively coupled to the DP resource(s) 1112 and configured to monitor the health of the DP resource(s) 1112. In some embodiments, the CP monitoring component 1110 may be configured to transmit (e.g., to a user device using any suitable form of electronic communication) any suitable health data indicative of the health of one or more of the DP resource(s) 1112. As an example, the CP monitoring component 1110 may transmit any suitable health data to a user device via the control plane API 1106.

[0089] In some embodiments, the CP monitoring component 1110 may be configured to monitor and evaluate current state data of the DP resource(s) 1112. In some embodiments, the CP monitoring component 1110 may store / update the current state data of the DP resource(s) 1112 in the CP data store 1108. The current state data may be provided by the DP manager 1122 to a corresponding CP worker, which may provide the current state data to the in-memory workflow manager 820, which may provide the current state data to the CP monitoring component 1110. In some embodiments, the CP worker(s) 1118 and / or the in-memory workflow manager 1116 may directly update the CP data store 1108 with the current state data of any appropriate DP resource, such that the current state data of a given DP resource is retrieved by the CP monitoring component 1110 at any appropriate time.

[0090] Although the CP monitoring component 1110, the in-memory workflow manager 1116, and the CP worker(s) 1118 are shown as separate components of the control plane 1102, in some embodiments, any suitable combination of the CP monitoring component 1110, the in-memory workflow manager 1116, and / or the CP worker(s) 1118 may be provided by a single service (e.g., service 706 in FIG. 7, an example of one of the services 502 in FIG. 5).

[0091] 12 is a block diagram illustrating an example method 1200 for providing in-memory workflow management at an edge computing device, according to at least one embodiment. Method 1200 may be performed by any suitable number of service provider computers (e.g., the service provider computers of FIG. 8). In some embodiments, method 1200 may include more or fewer steps than those shown in FIG. 12. It should be understood that the steps of method 1200 may be performed in any suitable order.

[0092] Method 1200 may begin at 1202, where a first user request specifying a first set of services to be executed at a first cloud computing edge device may be received by a computing device operated by a cloud computing provider. An example of this computing device may include service provider computer 802 of FIG. 8. In some embodiments, the cloud computing edge device may be a device configured to selectively execute within an isolated computing environment while executing within the isolated computing environment without access to a public network. For example, the cloud computing edge device may be an example of an edge device described above with respect to FIGS. 1-8, 10, and 11.

[0093] At 1204, a first manifest may be generated based at least in part on the first user request. The first manifest may specify a first configuration for the first cloud computing edge device. In some embodiments, the first configuration configures a first set of services according to the first user request. The first manifest may be an example of manifest 900 of FIG. 9.

[0094] At 1206, a first cloud computing edge device may be provisioned with a first set of services according to the first manifest.

[0095] At 1208, a second user request specifying a second set of services to run at a second cloud computing edge device may be received by the computing device. In some embodiments, the second set of services may be different from the first set of services.

[0096] At 1210, a second manifest may be generated based at least in part on the second user request. In some embodiments, the second manifest specifies a second configuration for the second cloud computing edge device, the second configuration including a second set of services. The second manifest may be another example of manifest 900 of FIG. 9.

[0097] At 1212, a second cloud computing edge device may be provisioned with a second set of services according to the second manifest. In some embodiments, the second cloud computing edge device may be provisioned with different services than the services provisioned at the first cloud computing edge device.

[0098] While specific embodiments have been described, various modifications, variations, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments are not limited to operation in a particular data processing environment, but can freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of operations and steps, it will be apparent to those skilled in the art that the scope of the present disclosure is not limited to the sequence of operations and steps described. Various features and aspects of the above-described embodiments can be used individually or jointly.

[0099] Furthermore, while embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments can be implemented solely in hardware, solely in software, or using a combination thereof. Various processes described in this disclosure can be executed on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform a particular operation, that configuration can be achieved, for example, by designing electronic circuitry to perform the processing, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or a combination thereof. Processes can communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication. Different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times. Embodiments can be implemented using a computer program product including computer program instructions that, when executed by a processor, cause the processor to perform any of the methods described in the present disclosure.

[0100] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions and other modifications and alterations may be made without departing from the broad spirit and scope defined by the appended claims. Accordingly, while particular embodiments of the present disclosure have been described, these embodiments are not intended to be limiting. Various modifications and equivalents are intended to be encompassed within the scope of the appended claims.

[0101] As used in the context of describing this disclosure (particularly in the context of the claims), the indefinite articles "a," "an," "the," and similar references should be construed to include both the singular and the plural unless otherwise stated in this disclosure or the context clearly indicates otherwise. The terms "comprising," "having," "including," and "containing" should be construed as open-ended terms (i.e., meaning "including, but not limited to") unless otherwise indicated. The term "connected" should be construed as being partly or wholly contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​in this disclosure is intended merely to serve as a shorthand method for individually referencing each individual value falling within the range, and unless otherwise stated herein, each individual value is incorporated into this disclosure as if it were individually set forth herein. Unless otherwise stated herein or the context clearly indicates otherwise, all methods described herein can be performed in any suitable order. Any examples described herein, or the use of exemplary language (e.g., "such as"), are intended merely to further clarify embodiments and do not limit the scope of the disclosure unless otherwise stated. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the disclosure.

[0102] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in context as generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specified. Thus, such disjunctive language is not generally intended to, nor does it imply, that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z be present.

[0103] Preferred embodiments of the present disclosure, including the best mode known for carrying out the disclosure, are described herein. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art can employ such variations as appropriate, and the present disclosure may be practiced in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Furthermore, unless expressly stated otherwise herein, all combinations of the elements described above in all possible variations thereof are encompassed by the present disclosure.

[0104] All references cited herein, including publications, patent applications, and patents, are incorporated by reference to the same extent as if each individual reference was individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0105] In the foregoing specification, aspects of the disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Moreover, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense.

Claims

1. 1. A computer-implemented method comprising: a computing device operated by a cloud computing provider receiving a first user request specifying a first set of services to be executed at a first cloud computing edge device, the cloud computing edge device being a device configured to selectively execute within an isolated computing environment without access to a public network while executing within the isolated computing environment, the method further comprising: and generating, based at least in part on the first user request, a first manifest for the first cloud computing edge device, the first manifest specifying a first configuration for the first cloud computing edge device, the first configuration including the first set of services, the method further comprising: the computing device provisioning the first set of services on the first cloud computing edge device according to the first manifest; receiving, by the computing device, a second user request specifying a second set of services to be executed at a second cloud computing edge device; and generating, by the computing device, a second manifest that specifies a second configuration for the second cloud computing edge device based at least in part on the second user request, the second configuration including a second set of services, the method further comprising: the computing device provisioning the second set of services on the second cloud computing edge device according to the second manifest.

2. 10. The computer-implemented method of claim 1, wherein at least one of the first manifest or the second manifest is predefined and further specifies at least one of a serial number associated with a cloud computing edge device, a hostname corresponding to the cloud computing edge device, a media access controller having an address corresponding to a network interface device of the cloud computing edge device, or one or more network addresses corresponding to one or more services.

3. 2. The computer-implemented method of claim 1, wherein the first cloud computing edge device is one of a plurality of cloud computing edge devices configured to operate as a computing cluster within the isolated computing environment, and the first manifest specifies a corresponding set of services to run at each cloud computing edge device of the plurality of cloud computing edge devices.

4. The computer-implemented method of claim 1 , wherein the first set of services and the second set of services are the same.

5. 2. The computer-implemented method of claim 1, wherein generating the first manifest includes obtaining artifacts corresponding to each service of the first set of services specified in the first user request.

6. 2. The computer-implemented method of claim 1, wherein generating the first manifest includes executing one or more executable scripts individually associated with artifacts corresponding to services in the first set of services, and wherein executing the one or more executable scripts modifies the first manifest to include one or more entity definitions, each entity definition corresponding to a device or a service.

7. The computer-implemented method of claim 1 , wherein generating the first manifest includes assigning network addresses to one or more entities defined in the manifest.

8. 1. A computing device comprising: one or more processors; one or more memories containing computer-executable instructions that, when executed by the one or more processors, cause the computing device to: receiving a first user request specifying a first set of services to be executed at a first cloud computing edge device, the cloud computing edge device being a device configured to selectively execute within an isolated computing environment without access to a public network while executing within the isolated computing environment, the computing device being operated by a cloud computing provider, the computer-executable instructions further causing the computing device to: The computer-executable instructions further cause the computing device to: generate, based at least in part on the first user request, a first manifest specifying a first configuration for the first cloud computing edge device, the first configuration including the first set of services; causing the first cloud computing edge device to provision the first set of services according to the first manifest; receiving a second user request specifying a second set of services to be executed at a second cloud computing edge device; generating a second manifest specifying a second configuration for the second cloud computing edge device based at least in part on the second user request, the second configuration including the second set of services, the computer-executable instructions further comprising: A computing device that causes the second cloud computing edge device to provision the second set of services according to the second manifest.

9. 10. The computing device of claim 8, wherein at least one of the first manifest or the second manifest is predefined and further specifies at least one of a serial number associated with a cloud computing edge device, a hostname corresponding to the cloud computing edge device, a media access controller having an address corresponding to a network interface device of the cloud computing edge device, or one or more network addresses corresponding to one or more services.

10. 10. The computing device of claim 8 or 9, wherein the first cloud computing edge device is one of a plurality of cloud computing edge devices configured to operate as a computing cluster within the isolated computing environment, and the first manifest specifies a corresponding set of services to run on each cloud computing edge device of the plurality of cloud computing edge devices.

11. 10. The computing device of claim 8 or 9, wherein the first set of services and the second set of services are the same.

12. 10. The computing device of claim 8 or 9, wherein generating the first manifest includes obtaining artifacts corresponding to each service of the first set of services specified in the first user request.

13. 10. The computing device of claim 8 or 9, wherein generating the first manifest includes executing one or more executable scripts individually associated with artifacts corresponding to services in the first set of services, and executing the one or more executable scripts modifies the first manifest to include one or more entity definitions, each entity definition corresponding to a device or a service.

14. 10. The computing device of claim 8 or 9, wherein generating the first manifest includes assigning network addresses to one or more entities defined in the manifest.

15. A computer program that causes a computing device to perform the method according to any one of claims 1 to 7.

Images