Decentralized Compute Infrastructure Offloading Workloads to Client Devices
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing decentralized computing solutions are resource-intensive and insecure, as they rely on heavyweight technologies like Kubernetes and Docker, leading to battery drain and CPU consumption, and pose security risks due to potential malicious containers that can exfiltrate data.
Innovation Solution
A decentralized compute infrastructure that determines whether to execute workloads in the cloud or on a client device, using a client orchestrator to evaluate orchestration criteria against device capabilities and capacity, and includes a crediting mechanism for cost savings shared among stakeholders, leveraging blockchain for secure transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If decentralized computing uses heavyweight technologies like Kubernetes and Docker, then service orchestration and container management are improved, but resource consumption (battery drain and CPU) increases
Solution Approach 1:
The patent extracts the heavy orchestration layer (Kubernetes/Docker) from the client device and relocates it to the cloud. The client device only runs lightweight runtime agents that execute containerized workloads, while all management, orchestration, and control plane functions remain in the cloud. This extraction eliminates the resource overhead of full container runtime on client devices.
Solution Approach 2:
The patent introduces a cloud-based Kubernetes control plane as an intermediary between the service provider and client devices. This control plane manages workload deployment, scheduling, and orchestration remotely, allowing client devices to run containers without local orchestration infrastructure. The intermediary handles all complex decision-making centrally.
2Productivity
If containers are downloaded and executed on client devices, then local compute capability is improved, but security risks increase due to potential malicious containers
Solution Approach 1:
The patent implements preliminary security validation in the cloud before containers are deployed to client devices. The Kubernetes control plane performs security scanning, vulnerability assessment, and authorization checks on all container images and workloads before allowing them to be pulled and executed on client devices. This preliminary action prevents malicious containers from reaching the edge.
Solution Approach 2:
The cloud-based Kubernetes control plane acts as a security intermediary that mediates between the container registry and client devices. It validates container integrity, enforces security policies, and controls the deployment process, preventing direct execution of unverified containers on client systems.
3Reliability
If workloads are executed in the cloud, then security and control are improved, but latency and cloud costs increase
Solution Approach 1:
The patent segments the computing workload into two parts: security-critical functions remain in the cloud (control plane, authentication, logging), while compute-intensive workloads are executed locally on client devices. This segmentation allows security and control to be maintained centrally while latency-sensitive operations run at the edge.
Solution Approach 2:
The patent transitions from a single-cloud deployment model to a hybrid cloud-edge architecture, adding a spatial dimension to the deployment topology. Workloads are distributed across multiple dimensions (cloud control plane, edge execution nodes), allowing simultaneous optimization of security (cloud) and latency (edge).
Data Source
AI summary
Embodiments described herein are generally directed to decentralized compute infrastructure (DCI). According to one embodiment, a determination is made by a recommendation engine running on a client computer system to offload a particular non-containerized workload associated with a host application from a SaaS cloud to the client computing system on which the host application is also running. After the determination, a unit of execution in which the particular workload is packaged may be fetched and the non-containerized workload may be caused to be run locally on the client computing system. In some examples, a metric indicative of cost savings accrued by a vendor of the host application due to offloading may be tracked and at least a portion of the cost savings may be distributed to one or both of a subscriber of the host application and one or more third party stakeholders.