Distributed computing infrastructure
By introducing migration mechanisms and client orchestrators in the decentralized computing infrastructure, the problems of high resource consumption and insufficient security models in the prior art are solved, and more efficient local computing and cloud cost savings are achieved.
Patent Information
- Application Number
- CN202411180230.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-09-29
- Filing Date
- 2024-08-27
- Publication Date
- 2025-04-01
AI Technical Summary
Existing decentralized computing technologies have problems with high resource consumption and insufficient security models when migrating containerized workloads from the cloud to client devices.
By introducing migration mechanisms and client orchestrators in a decentralized computing infrastructure, we evaluate the capabilities and capacity of client devices, and decide whether to migrate specific workloads from the cloud to client devices, and use blockchain for cost-saving sharing when necessary.
Improves utilization of on-premises computing power, improves waiting time and privacy, reduces cloud costs, and promotes widespread support and participation of decentralized computing infrastructure.
Smart Images

Figure CN119739491A_ABST
Abstract
Description
Technical Field
[0001] The embodiments described herein relate generally to the field of distributed computing, and more specifically, to a distributed computing infrastructure that facilitates migration decisions and deployment modules, for example, for developers who wish to utilize local computing but still use the cloud to support host applications (e.g., web applications and / or native applications) when needed. Background Art
[0002] Computing is centralized when critical application services are performed only through communications with a remote central location, such as when different users in different locations connect to the same service or address to access computing resources (such as data storage and processing). In contrast, computing is decentralized when critical application services are or can be performed by separate computing devices or nodes on a distributed network, such as on behalf of users of the separate computing devices or nodes and / or on behalf of other parties.
[0003] Decentralized infrastructure is an approach to implementing and operating digital infrastructure networks that reduces reliance on one centralized model or service provider, such as Software-as-a-Service (SaaS) providers (e.g., streaming service providers, online gaming providers, and / or other independent software vendor (ISV) solutions delivered via a SaaS model), and instead allows individuals and businesses to potentially participate in the network as service providers (on behalf of themselves or others). Such participation can address challenges associated with traditional centralized networks, such as cost, risk, and scale, as well as lower barriers to access and participation.
[0004] In the era of decentralized computing, service providers and ISVs can provide incentives for migrating user sessions from cloud instances to client devices, and the resulting cost savings can be governed and compensated through transactions recorded on the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The embodiments described herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references refer to similar elements.
[0006] Figure 1A is a high-level block diagram illustrating a first example of an operating environment supporting a decentralized compute infrastructure (DCI) according to some embodiments.
[0007] Figure 1Bis a high-level block diagram illustrating a second example of an operating environment supporting DCI according to some embodiments.
[0008] Figure 2 is a block diagram illustrating a first example of a software architecture for a personal computer supporting DCI according to some embodiments.
[0009] Figure 3 is a block diagram illustrating a second example of a software architecture for a personal computer supporting DCI according to some embodiments.
[0010] Figure 4 is a block diagram illustrating a third example of a software architecture for a personal computer supporting DCI according to some embodiments.
[0011] Figure 5 is a block diagram illustrating a fourth example of a software architecture for a personal computer supporting DCI according to some embodiments.
[0012] Figure 6 is a block diagram illustrating a fifth example of a software architecture for a personal computer supporting DCI according to some embodiments.
[0013] Figure 7 is a flow diagram illustrating operations associated with utilizing a host application flow of a recommendation service in accordance with some embodiments.
[0014] Figure 8 is a flow diagram illustrating operations for performing a migration authorization process in accordance with some embodiments.
[0015] Fig. 9 is a flow diagram illustrating operations for performing a recommendation process according to some embodiments.
[0016] Fig.10 is an example of a computer system that can be used to utilize some embodiments. DETAILED DESCRIPTION
[0017] The embodiments described herein are generally directed to a distributed computing infrastructure (DCI). Cloud native applications are typically containerized and then orchestrated by an orchestrator similar to Kubernetes in the cloud. Previous solutions for migrating user sessions to edge devices (e.g., client devices) involve, for example, opportunistically downloading containers from the cloud to a user's personal computer (PC) or laptop, and then instantiating them using a runtime infrastructure (including Kubernetes, Docker Runtime, and a control plane for triggering orchestration) installed on the client. One disadvantage of such existing solutions is that Kubernetes and Docket are heavy and resource-intensive, resulting in significant battery consumption and central processing unit (CPU) consumption, which reduces the locally available computing resources for other applications running on the client device. Since the downloaded container may be malicious and may leak information from the client device, access files on the client device through a ransomware attack, or otherwise damage the client device or its content, significant concerns have also been raised about the security model of this existing approach.
[0018] Various embodiments described herein seek to address or at least mitigate one or more of the limitations of existing distributed computing technologies for various use cases. As further described below, according to one embodiment, for example, a determination is made by a component of the proposed DCI as to whether a particular non-containerized workload associated with a host application is to be executed in the cloud or on a client computing system on which the host application is running. Upon determining that the particular workload is to be executed on the client computing system, an execution unit in which the particular workload is encapsulated can be obtained, and the particular workload can be caused to run locally on the client computing system.
[0019] In some embodiments, despite the above-described disadvantages associated with the migration of containerized workloads, it may still be worthwhile for a user (or subscriber) of a host application to allow the migration of a containerized workload from a SaaS cloud to a user's client computer system when the user can obtain compensation (e.g., via utility tokens, cryptocurrency, or a statement credit on their subscription invoice) based on the cost savings achieved as a result of the migration (e.g., CSP cost savings).
[0020] As further described below, the proposed approach for DCI may include one or more of the following components, distributed in various combinations between client devices, a SaaS cloud where a cloud-based service of a SaaS provider (e.g., an ISV or other provider of cloud-based services) is hosted by a CSP, and an optional blockchain:
[0021] A host application (e.g., a web application or a native application) that runs on a client device and represents a front-end (or user interface) application through which the SaaS provider's cloud-based services can be accessed by users and which communicates with workloads associated with the cloud-based services, such as via representational state transfer (REST) API calls.
[0022] A migration mechanism (e.g., an orchestration service) operable within a SaaS cloud or cloud-based service that provides orchestration criteria to a requester (e.g., a client orchestrator) to allow the requester to evaluate whether to migrate a particular workload associated with a host application from the SaaS cloud to a client device on which the host application runs.
[0023] A client orchestrator (or migration recommendation engine) operable on a client device that evaluates orchestration criteria against the capabilities of the client device (e.g., static configuration) and / or the capacity of the client device (e.g., current dynamic state) to make a recommendation as to whether to transfer a given workload to the client device.
[0024] · Credit or monetization mechanisms (e.g., payment smart contacts or statement credits for paid services) to facilitate the sharing of savings among one or more of the various stakeholders (e.g., owners of client devices, ISVs, and / or one or more other solution providers that facilitate or contribute to some aspect of the proposed DCI).
[0025] Telemetry or metering services that capture appropriate metrics that can be used to determine or otherwise estimate the savings resulting from running a given workload on a client device.
[0026] Advantageously, various embodiments better utilize local computing power and can provide improved latency and privacy. Additionally, reduced cloud costs incurred by SaaS providers can be shared among one or more of the various stakeholders, thereby encouraging support and participation in the proposed solution.
[0027] In the following description, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. However, it will be apparent to one skilled in the art that the embodiments described herein may be practiced without some of these specific details.
[0028] the term
[0029] The terms "connected" or "coupled" and related terms are used in an operational sense and are not necessarily limited to direct connections or couplings. Thus, for example, two devices may be coupled directly, or via one or more intermediate media or devices. As another example, devices may be coupled in such a way that information may be transferred between them while not sharing any physical connection with each other. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate the various ways in which there are connections or couplings according to the foregoing definitions.
[0030] If the specification states a component or feature "may," "might," "could," or "can" be included or have a property, that particular component or feature is not required to be included or have the property.
[0031] As used in the description herein and throughout the claims that follow, the meanings of "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Additionally, as used in the description herein, the meaning of "in" includes "in" and "on," unless the context clearly dictates otherwise.
[0032] A "host application" generally refers to an application that runs on a client computer system. Non-limiting examples of host applications include web applications (or apps) and native applications (or apps).
[0033] "Web application" or "web app" generally refers to a host application that runs within a web browser. A web app generally only gives users access to interactions supported by the web browser. Thus, even though a web application may have rich design elements, it cannot access device features.
[0034] A "native application" generally refers to a host application that has been developed for a specific operating system of a client computing system, thereby allowing the client computing system to run natively on the specific operating system.
[0035] "Execution unit" or "computing unit" generally refers to a software package representing an application or program. Execution units can be packaged in different formats. Non-limiting examples of execution units include containers (independent software units that encapsulate code and all its dependencies so that individual applications run quickly and reliably from one computing environment to another), WebAssembly (WASM) modules, and machine learning (ML) models (e.g., programs or outputs generated after training an ML algorithm on training data). Non-limiting examples of ML models include Open Neural Network eXchange (ONNX) models and TensorFlow (TF) models.
[0036] As used herein, "WebAssembly" or "WASM" generally refers to a portable binary code format and a corresponding text format for executable programs that conform to the current or future versions of the WebAssembly specification published on the WebAssembly.org website. WASM also defines a software interface for facilitating interaction between an executable program and its host environment. WASM allows developers to run native code in a web browser. Unlike JavaScript, which is an interpreted language, WASM is a low-level language that is designed to be compiled from other programming languages similar to C and C++. This makes it possible to run high-performance code in a browser, which was not possible before. WASM is supported by all mainstream browsers, including Chrome, Firefox, Safari, and Edge, and therefore does not require a separate runtime environment when running in such browsers.
[0037] A "workload" generally refers to an application or program running on a computer system or within a computing environment (e.g., a virtual machine, a runtime environment, a container orchestration platform such as Kubernetes). Non-limiting examples of workloads include computationally intensive tasks (e.g., image processing, simulation, optimization, etc.), putting ML models into production or implementing ML models to make predictions or inferences, or other processes that involve complex computations and require a large amount of processing power from processing resources (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or an xPU (e.g., a data processing unit (DPU), an infrastructure processing unit (IPU), a function accelerator card (FAC), a network attached processing unit (NAPU), or other processing units that can migrate and accelerate specialized tasks more efficiently than a general-purpose CPU)). In various embodiments described herein, a workload may be referred to as a containerized workload or a non-containerized workload. A "containerized workload" generally refers to a workload that is encapsulated within a container. “Non-containerized workloads” generally refer to workloads that are not encapsulated within a container. Non-limiting examples of non-containerized workloads include workloads associated with WASM modules or ML models.
[0038] As used herein, "cloud" or "cloud environment" refers broadly and generally to a platform through which cloud computing can be delivered via a public network (e.g., the Internet) and / or a private network. The National Institute of Standards and Technology (NIST) defines cloud computing as "a model for enabling ubiquitous, convenient, on-demand network access to a pool of shared configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction" P. Mell, T. Grance, NIST Cloud Computing Definition, National Institute of Standards and Technology, 2011. The cloud infrastructure can be deployed according to a variety of deployment models, including private clouds, community clouds, public clouds, and hybrid clouds. In a private cloud deployment model, the cloud infrastructure is provided for exclusive use by a single organization including multiple consumers (e.g., business departments), and can be owned, managed, and operated by the organization, a third party, or a combination thereof, and can exist internally or externally. In the community cloud deployment model, the cloud infrastructure is provided for exclusive use by a specific community of consumers from organizations with shared concerns (e.g., missions, security requirements, policies, and compliance considerations), may be owned, managed, and operated by one or more of the organizations in the community, a third party, or a combination thereof, and may exist internally or externally. In the public cloud deployment model, the cloud infrastructure is provided for open use by the general public, may be owned, managed, and operated by a cloud service provider (e.g., a commercial, academic, or government organization, or a combination thereof), and exists at the premises of a cloud service provider (CSP). A CSP may provide cloud-based platform, infrastructure, application, or storage services as a service according to a variety of service models, including software as a service (SaaS), platform as a service (PaaS), and / or infrastructure as a service (IaaS). Similarly, an ISV representing a subscriber of a CSP may deliver solutions to its customers or subscribers from a public cloud operated by a CSP via a SaaS model. In a hybrid cloud deployment model, the cloud infrastructure is a composite of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities but are linked together by standardized or proprietary technologies that enable portability and mobility of data and applications (e.g., cloud bursting for load balancing between clouds).
[0039] As used herein, "migration policy," "migration criteria," or "application preference" generally refers to criteria that specify conditions under which a given workload is permitted or not permitted to be migrated from the cloud to a client computing system. Non-limiting examples of migration criteria include one or more aspects of static configuration (e.g., minimum system configuration, number of CPUs, number of CPU cores, amount of system memory, presence of GPUs, presence of xPUs, etc.) or capabilities of the client computing system, and one or more aspects of dynamic state (e.g., CPU utilization, GPU utilization, xPU utilization, whether the system is running on battery or plugged in, battery charge, network conditions (such as congestion), availability of sufficient memory and / or processing resources to perform a minimum number of inferences per unit time, availability of sufficient memory to accommodate the size of the model in question, etc.) or capacity of the client computing system. As further explained below, migration policies can be defined and hosted in a SaaS cloud for a given workload, or can be built into a host application.
[0040] “Digital tokens” or “crypto tokens” generally refer to digital assets or cryptocurrencies that can be used to facilitate transactions or digital representations of asset interests on a blockchain. Non-limiting examples of digital tokens include transaction tokens, governance tokens, utility tokens, security tokens, platform tokens, and non-fungible tokens (NFTs). Digital tokens can be created according to a variety of different token standards, for example, Ethereum Request for Comments 20 (ERC-20) is a technical standard for fungible tokens (ERC-20 tokens) created using the Ethereum blockchain, and Binance Smart Chain Evolution Proposal 20 (BEP-20) is a technical standard for fungible tokens (BEP-20 tokens) created using BNB Smart Chain (BCS) (formerly known as Binance Smart Chain).
[0041] As used herein, the terms "module", "component", "engine", "service", etc. are intended to refer to a computer-related entity: software executing a general-purpose processor, hardware, firmware, or a combination thereof. For example, a module or component can be, but is not limited to, a process, an executable file, an execution thread, a program, and / or a computer running on a computing resource.
[0042] Example operating environment
[0043] Figure 1A is a high-level block diagram illustrating a first example of an operating environment 100 supporting a distributed computing infrastructure (DCI) according to some embodiments. In the context of this example, operating environment 100 is shown to include client computer system 110 and SaaS cloud 130.
[0044] Client computer system 100 may represent a smartphone, tablet, or personal computer such as a laptop or desktop, and may include a host application 115 , a recommendation engine 116 , an execution unit 142 , and a workload 143 .
[0045] The host application 115 may represent a web application or a native application of a SaaS provider (e.g., a streaming service provider, an online gaming provider, an online collaboration service provider, and / or other provider (such as an ISV) of cloud-based services (e.g., cloud-based business 131) delivered via a SaaS model. For example, using a streaming service provider (e.g., Spotify or Netflix) as an example, the host application 115 may represent a front-end (or user interface) application (through which songs, playlists, TV shows, or movies may be played) in the form of a native application (e.g., a Spotify application or a Netflix application) that may be downloaded, installed, and run natively on the client computer system 110. Alternatively, the host application 115 may represent a front-end application in the form of a web application (e.g., a web player or a browser-based version of the Spotify application or the Netflix application) that may, for example, employ JavaScript and execute within a web browser (not shown) running on the client computer system 110 when a user is logged into their account.
[0046] Recommendation engine 116 may represent a client orchestrator (or migration recommendation engine) operable on client computer system 110. Recommendation engine 116 may be responsible for evaluating application criteria 141 relative to the capabilities (e.g., static system configuration 111) and / or current dynamic state 112 of client computer system 110 to make a recommendation as to whether to transfer a given workload (e.g., workload 143) from SaaS cloud 130 to client computer system 110. Application preferences 141 may specify one or more criteria that define the conditions under which a given workload (e.g., workload 143) may be permitted or not permitted to be migrated from SaaS cloud 130 to client computing system 110. For example, in the case of a video encoding, video decoding, or video editing workload, application preferences 141 may specify a minimum system configuration that includes a GPU or CPU with at least six cores, and a threshold amount of random access memory (RAM), and a minimum availability of capacity of the GPU, CPU, and / or RAM to accommodate the workload in question. For example, in the case of an ML workload, the application preferences 141 may specify a minimum system configuration including a GPU or xPU (e.g., a neural processing unit), and a minimum availability of capacity of the GPU or xPU to accommodate the workload in question. Depending on the specific implementation, the recommendation engine 116 may be in the form of a separate application, or may be in the form of a library packaged with the host application 115.
[0047] Turning now to SaaS cloud 130, it can represent a particular public cloud (e.g., Amazon Web Services, Microsoft Azure, or Google Cloud Platform) contracted by a SaaS provider to host a CSP (Amazon, Microsoft, or Google, respectively) for cloud-based services 131. In the context of this example, SaaS cloud 130 is shown as including orchestration services 140 and workloads 143 within cloud-based services 131. As will be appreciated by those skilled in the art, host application 115 can communicate with workload 143 via API calls (e.g., API calls 113, which can be in the form of representational state transfer (REST) API calls, graph query language (GraphQL) API calls, gRPC remote procedure calls (gRPC), WebSocket API calls, etc.), or otherwise interact with cloud-based services 131.
[0048] Orchestration service 140 represents a migration mechanism operable within SaaS cloud 130 that can provide application preferences 141 to a requester (e.g., recommendation engine 116) to facilitate evaluation by the requester of whether to migrate a particular workload (e.g., workload 143) associated with host application 115 from SaaS cloud 130 to client computer system 110. After a migration decision has been made by recommendation engine 316 to run a particular workload locally, orchestration service 140 can be used to deliver a given execution unit (e.g., execution unit 142) (e.g., a container, a WASM module, an ML model (e.g., an Open Neural Network Exchange (ONNX) model or a TensorFlow model), etc.) from SaaS cloud 130 to client computer system 110, wherein the particular workload is packaged to allow the particular workload to run on selected processing resources (not shown) (e.g., a CPU, GPU, or xPU) of client computer system 110.
[0049] While in the context of this example, a given execution unit (e.g., execution unit 142) containing code representing and supporting a given workload (e.g., workload 143) is shown as initially residing in SaaS cloud 130 and selectively retrieved, e.g., by recommendation engine 116 or host application 115 for local execution on client computer system 110, it should be appreciated that the given execution unit may alternatively be stored in a separate repository from which the given execution unit may be retrieved as needed by SaaS cloud 130 and / or client computer system 110. Similarly, while only a single execution unit and a corresponding single workload are shown, it should be appreciated that multiple execution units and multiple corresponding workloads may be migrated from SaaS cloud 140 to client computer system 110.
[0050] Figure 1B 1 is a high-level block diagram illustrating a second example of an operating environment 101 supporting DCI according to some embodiments. In the context of this example, Figure 1A The operating environment is 100 Figure 1BThe differences between the operating environment 101 of the present invention and the present invention are the addition of various wallets 161a-n, the inclusion of telemetry service 150 within cloud-based service 131, and the addition of a crediting or monetization mechanism (e.g., payment smart contact 165 stored on blockchain 160) to facilitate the sharing of cost savings (e.g., reduced usage of CSP resources) achieved by migrating one or more workloads (e.g., workload 143) from the SaaS cloud to the client computer system 110. In one embodiment, such cost savings can be distributed among one or more of various stakeholders, such as the owner of the client computer system 110, an ISV, and / or one or more other solution providers (e.g., a developer of recommendation engine 116, a CSP, etc.) that promote or contribute to some aspect of the proposed DCI.
[0051] According to one embodiment, blockchain 160 may represent a layer 1 base network (or public blockchain network) (e.g., Ethereum blockchain) that is used to record in a trusted manner how much computational migration has occurred as a result of allowing one or more workloads (e.g., workload 143) to migrate from SaaS cloud 130 to client computer system 110. Depending on the specific implementation, a separate chain (e.g., a layer 2 or layer 3 blockchain / sidechain) may additionally or alternatively be used to provide privacy and confidentiality of metering data collected and transmitted to blockchain 160 (if desired by the SaaS provider).
[0052] The telemetry service 150 may be responsible for collecting metric data indicating cost savings accrued by the SaaS provider. Those skilled in the art will appreciate that there are a variety of methods to measure such cost savings, including, for example, (i) assigning a cost to each API call (e.g., API call 113) and tracking the number of API calls made by the host application 115, (ii) measuring the amount of migration based on the difference between CSP resource usage before and after a given workload is migrated to the client computer system 110 by the SaaS provider, and / or (iii) measuring resource usage (e.g., CPU cycles) performed by the client computer system 110 to execute a given workload. Depending on the specific implementation, metering of resource usage on the client computer system 111 or metering of CSP resource usage by the cloud-based service 131 is performed by the SaaS provider or with the assistance of a third-party SaaS metering service or public blockchain company (e.g., Akash.network, Sonm, Golem, Fluence, Spheron, etc.).
[0053] The telemetry service 150 may also determine the amount of digital tokens to be distributed to one or more of the various stakeholders based on a predetermined or configurable algorithm or formula (e.g., which performs or is used to perform the conversion of a measurement or metric for estimating or tracking cost savings of a SaaS provider to a digital token and / or the allocation or sharing of cost savings). Such allocation or sharing of cost savings may be the subject of a formal cost savings sharing agreement between the various stakeholders and the SaaS provider. The cost savings sharing agreement may specify the terms and conditions and methods for performing tokenized metering. For example, based on the cost savings accrued by the SaaS provider over a period of time (e.g., a month) due to the migration performed by a given client computer system, a percentage of cost savings (e.g., 20% to 33%) may be allocated to the owner of the client computing system 110 (e.g., a user or subscriber of the cloud-based service 131). Additionally, a first solution provider (e.g., a developer of the recommendation engine 116) may be allocated a percentage (e.g., 20% to 33%) of the cost savings. Still further, a second solution provider (e.g., a CSP or other partner) may be allocated a percentage (e.g., 10% to 20%) of the cost savings. Any remaining cost savings may be retained by the SaaS provider. Alternatively, the SaaS provider may retain all of the cost savings.
[0054] According to one embodiment, the telemetry service 150 may periodically push collected metrics (in raw form or converted into digital tokens) to the payment smart contract 165 (and / or another crediting or monetization mechanism) that indicate cost savings accruing to the SaaS provider on a per-client device basis. The payment smart contract 165, for its part, may be responsible for crediting the stakeholder's wallet 161a-n.
[0055] While in the context of the present example, payment smart contract 165 is described as a non-limiting example of a credit or monetization mechanism for facilitating the sharing of cost savings (e.g., CSP resource utilization costs) among one or more of the various stakeholders to encourage participation in and / or support for the proposed DCI, it should be appreciated that statement credits may additionally or alternatively be issued periodically to subscribers of paid services (e.g., monthly or annual subscriptions to voice-based services 131). As yet another example of a credit or monetization mechanism, a SaaS provider may offer a discounted subscription plan to a subscriber who has a client computer system (e.g., client computer system 110) that has sufficient capacity and agrees to allow workloads of cloud-based services 131 (e.g., workload 143) to be migrated to the client computer system as appropriate.
[0056] Example Client Device Software Architecture
[0057] Figure 2 2 is a block diagram illustrating a first example of a software architecture of a personal computer 210 for supporting DCI according to some embodiments. In the context of this example, the personal computer 210 (which may be similar to the client computer system 110) is shown interacting with a SaaS cloud 230 (which may be similar to the SaaS cloud 130). In one embodiment, the personal computer 210 includes a web browser 220 (e.g., Google Chrome, Firefox, Microsoft Edge, Internet Explorer, etc.), a recommendation engine 216 (which may be similar to the recommendation engine 116), an operating system 260, and a set of one or more processing resources 270.
[0058] Depending on the static system configuration of the personal computer 210 , a set of one or more processing resources 270 may include one or more CPUs 271 , one or more GPUs 272 , and one or more xPUs 273 .
[0059] Operating system 260 may represent a current or future version of the Microsoft Windows operating system, one of a variety of currently available or future Linux operating system distributions (e.g., Deepin, Fedora, Zorin OS, Solus, Debian, Ubuntu, Linux Mint, etc.), etc. Operating system 260 is shown to include a native ML API 265 (e.g., a low-level API for ML), which may provide high-performance, hardware-accelerated ML primitives to support ML model inference, etc. Non-limiting examples of native ML API 265 include Direct Machine Learning (DirectML). Native ML API 265 may facilitate efficient execution of inference models on a GPU (e.g., one of GPUs 272) and / or an artificial intelligence (AI)-accelerated core (e.g., one of xPUs 273).
[0060] Web browser 220 may run web application 215 retrieved by web browser 220 from SaaS cloud 230 , for example, as a result of a user utilizing or otherwise accessing a cloud-based service (eg, cloud-based service 131 ) provided by a SaaS provider and hosted by a CSP in SaaS cloud 230 .
[0061] Web application 215 can be coded in JavaScript and can represent a front-end application through which interaction with cloud-based services is implemented. In the context of this example, web application 215 is shown as including ONNX runtime 222 and TensorFlow (TF) runtime 223, which are used to execute ONNX model 218 and TF model 219, respectively, which can represent an execution unit in which workload 243 (which can be similar to workload 143) is encapsulated. Web application 215 is also shown as including web API 217, which represents an interface through which web application 215 can utilize native ML API 265. Depending on the specific implementation, web API 217 can represent a JavaScript API. Non-limiting examples of Web API 215 include a Web Graphics Library (WebGL) API that facilitates rendering of high-performance interactive three-dimensional (3D) and two-dimensional (2D) graphics within a compatible web browser, and a Web Neural Network (WebNN) API that allows web applications such as web application 215 to leverage on-device hardware such as GPU 272, CPU 271, or purpose-built AI accelerators (e.g., the neural processing unit of xPU 273) to accelerate deep neural networks.
[0062] When migration is enabled or otherwise authorized for execution by personal computer 210, before retrieving an execution unit containing a given workload (e.g., workload 243) for local execution, web application 215 can request recommendation engine 216 to evaluate the capabilities and capacity of personal computer 210 for accommodating the transfer of the given workload from SaaS cloud 230 to personal computer 210, for example based on one or more of a static system configuration associated with the given workload (e.g., system configuration 111), a current dynamic state of personal computer 210 (e.g., dynamic state 112), and application preferences 241 (which can be similar to application preferences 141). In addition, recommendation engine 216 can select the most appropriate processing resource from processing resources 270 for the given workload. Fig. 9 Non-limiting examples of recommendation processing that may be performed by the recommendation engine 216 are further described.
[0063] Figure 3is a block diagram illustrating a second example of a software architecture of a personal computer 310 for supporting DCI according to some embodiments. In the context of this example, personal computer 310 (which may be similar to client computer system 110) is shown interacting with SaaS cloud 330 (which may be similar to SaaS cloud 130). In one embodiment, personal computer 310 includes native application 315 (which may be similar to host application 115), recommendation engine 316 (which may be similar to recommendation engine 116 or 216), operating system 360 (which may be similar to operating system 260), and a set of one or more processing resources 370 (which may be similar to processing resource 270).
[0064] Operating system 360 is shown as including native ML API 365 (which may be similar to native ML API 265 ).
[0065] Native application 315 may represent a front-end application through which interaction with a cloud-based service (e.g., cloud-based service 131) provided by a SaaS provider hosted by a CSP in SaaS cloud 330 is facilitated. In the context of this example, native application 315 is shown to include model 318 (e.g., ONNX model, TF model, etc.), which may represent an execution unit in which a workload (not shown) is encapsulated.
[0066] As described above, when migration is enabled or otherwise authorized for execution by personal computer 310, before retrieving an execution unit (e.g., model 318) containing a given workload for local execution, native application 315 may request recommendation engine 316 to evaluate the capabilities and capacity of personal computer 310 for accommodating the transfer of the given workload from SaaS cloud 330 to personal computer 310, for example, based on one or more of a static system configuration associated with the given workload (e.g., system configuration 111), a current dynamic state of personal computer 310 (e.g., dynamic state 112), and application preferences 341 (which may be similar to application preferences 141). In addition, recommendation engine 316 may select the most appropriate processing resource from processing resources 370 for the given workload.
[0067] Figure 44 is a block diagram illustrating a third example of a software architecture of a personal computer 410 for supporting DCI according to some embodiments. In the context of this example, the personal computer 410 (which may be similar to the client computer system 110) is shown as interacting with a SaaS cloud 430 (which may be similar to the SaaS cloud 130). In one embodiment, the personal computer 410 includes a WASM application 315 (which may be similar to the host application 115), a recommendation engine 416 (which may be similar to the recommendation engine 116 or 216), a WASM runtime 480, an ML framework 490, an operating system 460 (which may be similar to the operating system 260), and a set of one or more processing resources 470 (which may be similar to the processing resource 270).
[0068] ML framework 490 may represent any tool, interface, or library that facilitates the construction and deployment of ML models. Non-limiting examples of ML framework 690 include ONNX, TensorFlow, Keras, H2O, Shogun, Scikit Learn, and PyTorch.
[0069] The WASM runtime 480 may represent a compiler and runtime (e.g., the WASM module 443) for compiling WASM code and a virtual machine for running the resulting WASM binary.
[0070] Operating system 460 is shown as including native ML API 465 (which may be similar to native ML API 265 ).
[0071] WASM application 415 may represent a front-end application through which interaction with a cloud-based service (e.g., cloud-based service 131) provided by a CSP-hosted SaaS provider in SaaS cloud 430 is facilitated. In the context of this example, WASM application 415 is shown to include model 418 and WASM module 443, which may represent an execution unit in which a workload (e.g., model 418) is encapsulated. Non-limiting examples of model 418 include ONNX models and TF models.
[0072] As described above, when migration is enabled or otherwise authorized to be performed by personal computer 410, before retrieving an execution unit (e.g., WASM module 443) containing a given workload (e.g., model 418) for local execution, WASM application 415 can request recommendation engine 416 to evaluate the capabilities and capacity of personal computer 410 for accommodating the transfer of a given workload from SaaS cloud 430 to personal computer 410, for example, based on one or more of a static system configuration associated with the given workload (e.g., system configuration 111), a current dynamic state of personal computer 410 (e.g., dynamic state 112), and application preferences 441 (which can be similar to application preferences 141). In addition, recommendation engine 416 can select the most appropriate processing resource from processing resources 470 for a given workload.
[0073] Figure 5 is a block diagram illustrating a fourth example of a software architecture of a personal computer 510 for supporting DCI according to some embodiments. In the context of this example, personal computer 510 (which may be similar to client computer system 110) is shown interacting with SaaS cloud 530 (which may be similar to SaaS cloud 130). In one embodiment, personal computer 510 includes a web browser 520 (which may be similar to web browser 220), a recommendation engine 516 (which may be similar to recommendation engine 116 or 216), an operating system 560 (which may be similar to operating system 260), a container runtime 580, and a set of one or more processing resources 570 (which may be similar to processing resource 270).
[0074] Web browser 520 may run web application 515 (which may be similar to web browser 215) retrieved by web browser 520 from SaaS cloud 530, e.g., as a result of a user utilizing or otherwise accessing a cloud-based service (e.g., cloud-based service 131) provided by a SaaS provider and hosted by a CSP in SaaS cloud 530. Web application 315 may represent a front-end application through which interaction with the cloud-based service is facilitated.
[0075] Container runtime 580 can represent a software component that can run containers on a host operating system (e.g., operating system 560). Non-limiting examples of container runtime 580 include Docker, containerd, and any implementation of the Kubernetes container runtime interface (CRI). In the context of this example, container runtime 580 is shown as running a containerized workload (e.g., container workload 543), which is downloaded to personal computer 510, for example, in the form of an execution unit (e.g., a container (not shown)), and instantiated using container runtime 580.
[0076] As described above, when migration is enabled or otherwise authorized to be performed by personal computer 510, before retrieving an execution unit (e.g., container) encapsulating a given container workload (e.g., container workload 543) for local execution, web application 515 can request recommendation engine 516 to evaluate the capabilities and capacity of personal computer 510 for accommodating the transfer of the given workload from SaaS cloud 530 to personal computer 510, for example, based on one or more of a static system configuration associated with the given workload (e.g., system configuration 111), a current dynamic state of personal computer 310 (e.g., dynamic state 112), and application preferences 541 (which can be similar to application preferences 141). In addition, recommendation engine 516 can select the most appropriate processing resource from processing resources 570 for the given workload.
[0077] Figure 6 6 is a block diagram illustrating a fifth example of a software architecture of a personal computer 610 for supporting DCI according to some embodiments. In the context of this example, the personal computer 610 (which may be similar to the client computer system 110) is shown as interacting with a SaaS cloud 630 (which may be similar to the SaaS cloud 130). In one embodiment, the personal computer 610 includes a web application or native application 615 (which may be similar to the web application 215 or the native application 315), a recommendation engine 616 (which may be similar to the recommendation engine 116), an ML framework 690 (which may be similar to the ML framework 490), a WASM runtime 680 (which may be similar to the WASM runtime 480), a control plane 685, an operating system 660, and a set of one or more processing resources 570 (which may be similar to the processing resources 270).
[0078] In the context of this example, ML framework 690 is shown as having models 618a-n deployed therein, which models 618a-n may each represent an ONNX model, a TF model, etc. In the context of this example, WASM runtime 680 is shown as executing WASM modules 643a-n corresponding to models 618a-n, respectively.
[0079] The control plane 685 may represent a distributed intelligent control plane for triggering the orchestration of execution units (eg, WASM modules 643a-n) retrieved from an external WASM and model repository 635 (eg, a WASM hub, etc.).
[0080] Operating system 660 is shown as including native ML API 665 (which may be similar to native ML API 265 ).
[0081] When migration is enabled or otherwise authorized for execution by personal computer 610, before retrieving an execution unit containing a given workload (e.g., models 618a-n) for local execution, web application or native application 615 may request recommendation engine 616 to evaluate the capabilities and capacity of personal computer 610 for accommodating the transfer of the given workload from SaaS cloud 630 to personal computer 610, for example based on one or more of a static system configuration associated with the given workload (e.g., system configuration 111), a current dynamic state of personal computer 210 (e.g., dynamic state 112), and application preferences 641 (which may be similar to application preferences 141). In addition, recommendation engine 616 may select the most appropriate processing resource from processing resources 670 for the given workload.
[0082] The various software components described herein (e.g., recommendation engines 116, 216, 316, 416, 516, and 616, host applications 115, cloud-based services 131, orchestration services 140, telemetry services 150, payment smart contracts 165, web browsers 220 and 520, web applications 215 and 515, native applications 315, WASM applications 415, WASM runtimes 480 and 680, ML frameworks 490 and 690, container runtimes 580, etc.), and the processes described below may be implemented in the form of executable instructions stored on one or more machine-readable media and executed by one or more processing resources (e.g., microcontrollers, microprocessors, CPU cores, CPUs, GPUs, xPUs, application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.), and / or in the form of other types of electronic circuit systems. For example, the processes may be implemented by various forms of one or more virtual or physical computer systems (such as, for example, the following references to Fig.10 The computer system described herein is executed.
[0083] Example host application and recommended service flow
[0084] Figure 7 is a flow chart illustrating operations associated with utilizing a host application flow of a recommendation service according to some embodiments. Figure 7 The described processes may be performed within operating environment 100 or 101 .
[0085] At block 710, a web application (e.g., web application 215) is retrieved from a SaaS cloud (e.g., SaaS cloud 230), for example, by a web browser (e.g., web browser 220) running on a client computer system (e.g., personal computer 210). For example, after a user logs into their account at a SaaS provider to access a cloud-based service (e.g., cloud-based service 131) provided by the SaaS provider, the JavaScript representing the web application can be downloaded by the web browser.
[0086] At block 720, the web application is executed on the client computer system.
[0087] At block 730, a migration authorization process may be performed by the web application. For example, when the web application is run for the first time or each time the web application is run, various checks may be performed to determine whether the migration of one or more workloads (e.g., workload 243) from the SaaS cloud to the client computer system is authorized by the user (e.g., the owner of the client computer system). Figure 8 Non-limiting examples of migration authorization processing are further described.
[0088] At decision block 740, a determination is made as to whether the migration was authorized in block 730. If so, processing continues to block 750; otherwise, processing branches to block 770.
[0089] At block 750, a recommendation process is performed. For example, a web application may request a recommendation engine (e.g., recommendation 216) for a recommendation on whether a given workload (e.g., workload 243) should be run locally. Fig. 9 Non-limiting examples of recommendation processing are further described.
[0090] At decision block 760 , it is determined whether the recommendation of block 750 is to run the workload locally. If so, processing continues to block 780 ; otherwise, processing branches to block 770 .
[0091] At box 770 , the workload in question is executed in the SaaS cloud 770 .
[0092] At block 780, an execution unit with the workload encapsulated therein is retrieved, for example, from a SaaS cloud or from an external repository (e.g., WASM and model repository 635). An execution unit may be a container, a WASM module (e.g., WASM module 443, or WASM modules 643a-n), or an ML model (e.g., ONNX model 218, TF model 219, etc.)
[0093] Although in the context of this example, blocks 750-790 are shown for a single workload, it should be appreciated that the recommended processing and selective execution of the workload in the SaaS cloud or on the client computer system cloud may be performed multiple times during a user interaction with a cloud-based service. Similarly, although this example is described with reference to a web application, the method is equally applicable to native applications (e.g., native application 315) and WASM applications (e.g., WASM application 415), although no web browser is involved.
[0094] Example Migration Authorization Process
[0095] Figure 8 is a flow chart illustrating operations for performing a migration authorization process according to some embodiments. Figure 8The described processing may be performed by a host application (e.g., host application 115) running on a client computer system (e.g., client computer system 110 or personal computer 210, 310, 410, 510, or 610). The host application may be a web application (e.g., web application 215, 515, or 615) running within a web browser (e.g., a web browser), a native application (e.g., native application 315 or 615), or a WASM application (e.g., WASM application 415).
[0096] At block 810, a user of the host application may be prompted about their willingness to allow one or more workloads associated with the host application to be migrated from the cloud (e.g., SaaS cloud 130) to the client computer system on which the host application is running. For example, during configuration of the host application, during the first run of the host application, or each time the host application is run, the host application may present the user with an option to allow or not allow the migration. In some embodiments, the host application may enable the user to accept or decline a formal cost savings sharing agreement, which may specify the terms and conditions of participation in the cost savings sharing agreement and the methods used to measure and share the cost savings achieved by the SaaS provider as a result of the migration performed by the client computer system.
[0097] At decision block 820, a determination is made as to whether the user has consented to perform the migration. If so, processing continues to block 830; otherwise, the migration authorization process is complete.
[0098] At box 830, the migration authorization flag can be set to indicate that the user agrees to allow the migration, and the user's wallet code is received from the user, for example to allow the user to share in the cost savings achieved by the SaaS provider as a result of the migration performed by the client computer system (e.g., by way of periodic distribution of digital tokens by or on behalf of the SaaS provider).
[0099] At box 840, with the cost savings shared with the user, a payment smart contract (e.g., payment smart contract 165) can be configured accordingly and deployed on a blockchain (e.g., blockchain 160).
[0100] Example Recommendation Processing
[0101] Fig. 9 is a flow chart illustrating operations for performing a recommendation process according to some embodiments. Fig. 9The described processing may be performed by a recommendation engine (e.g., recommendation engine 116, 216, 316, 416, 516, or 616) operable within a client computer system (e.g., client computer system 110 or personal computer 210, 310, 410, 510, or 610). As described above, the recommendation engine may be a standalone application or a library that may be packaged with a host application (e.g., host application 115). In the context of this example, assume that a workload (e.g., workload 143) is about to be executed to support a cloud-based service (e.g., cloud-based service 131) of a SaaS provider, and that the host application (e.g., host application 110) has requested a recommendation from the recommendation engine regarding whether to run the workload locally on the client computer system.
[0102] At block 910, the static system configuration (e.g., system configuration 111) and dynamic state (e.g., dynamic state 112) of the client computer system are evaluated with reference to application preferences (e.g., application preferences 141). The application preferences may specify conditions under which migration of a given workload from a SaaS cloud (e.g., SaaS cloud 130) to the client computing system is permitted or not permitted. For example, the application preferences may include one or more aspects of the static system configuration (e.g., minimum system configuration, number of CPUs, number of CPU cores, amount of system memory, presence of GPUs, presence of xPUs, etc.) or capabilities of the client computing system, and one or more aspects of the dynamic state (e.g., CPU utilization, GPU utilization, xPU utilization, whether the system is running on battery or plugged in, battery charge, network conditions (e.g., congestion), availability of sufficient memory and / or processing resources to perform a minimum number of inferences per unit time, availability of sufficient memory to accommodate the size of the model in question, etc.) or capacity of the client computing system. Depending on the specific implementation, application preferences may be defined and hosted in a SaaS cloud and accessible by a host application or recommendation engine (e.g., via an orchestration service (e.g., orchestration service 140)), or application preferences may be built into the host application.
[0103] At decision block 920, it is determined whether the client computer system has both the capability and capacity to accommodate the workload in question migrated from the SaaS cloud. If so, processing continues to block 930; otherwise, the recommendation process is complete.
[0104] At block 930, the most appropriate processing resource (e.g., one of processing resources 270) for execution of the workload in question may also be selected based on the characteristics of the workload in question, such as a CPU from among multiple available CPUs (e.g., 271), a GPU from among multiple available GPUs (e.g., GPU 272), or an xPU from among multiple available xPUs (e.g., xPU 273). For example, for workloads involving computationally intensive tasks, a CPU with lower utilization may be selected. Similarly, a GPU or xPU may be selected for performing prediction or inference associated with an ML workload.
[0105] Although in the context of this example, reference Figure 7-Figure 9 The flowchart of the present invention includes a plurality of enumerated blocks, but it should be understood that the example can include additional blocks before, after and / or between the enumerated blocks. Similarly, in some examples, one or more of the enumerated blocks can be omitted and / or executed in a different order.
[0106] Example Computer System
[0107] Fig.10 1000 is an example of a computer system 1000 with which some embodiments may be utilized. Computer system 1000 may represent some, all, or a subset of the components of a client computer system (e.g., client computer system 110) or a computer system associated with a SaaS cloud (e.g., SaaS cloud 130). It is worth noting that the components of computer system 1000 described herein are intended only to illustrate various possibilities. Example computer system 1000 should in no way limit the scope of the present disclosure. In the context of this example, computer system 1000 includes a bus 1002 or other communication mechanism for communicating information, and processing resources (e.g., one or more hardware processors 1004) coupled to bus 1002 for processing information. The processing resources may be, for example, one or more general-purpose microprocessors or system on a chip (SoC) integrated circuits.
[0108] The computer system 1000 also includes a main memory 1006, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 1002 for storing information and instructions to be executed by the processor 1004. The main memory 1006 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 1004. Such instructions, when stored in a non-transitory storage medium accessible to the processor 1004, present the computer system 1000 as a special-purpose machine customized to perform the operations specified in the instructions.
[0109] The computer system 1000 further includes a read only memory (ROM) 1008 or other static storage device coupled to the bus 1002 for storing static information and instructions for the processor 1004. A storage device 1010 (e.g., a magnetic disk, an optical disk, or a flash drive (made of flash memory chips)) is provided and coupled to the bus 1002 for storing information and instructions.
[0110] The computer system 1000 may be coupled to a display 1012, such as a cathode ray tube (CRT), a liquid crystal display (LCD), an organic light-emitting diode display (OLED), a digital light processing display (DLP), etc., via the bus 1002 for displaying information to a computer user. An input device 1014 including alphanumeric and other keys is coupled to the bus 1002 for communicating information and command selections to the processor 1004. Another type of user input device is a cursor control 1016, such as a mouse, trackball, touchpad, or cursor direction keys, for communicating direction information and command selections to the processor 1004 and for controlling cursor movement on the display 1012. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.
[0111] The removable storage medium 1040 may be any type of external storage medium, including but not limited to a hard disk drive, a floppy disk drive, Zip drives, Compact Disc–Read Only Memory (CD-ROM), Compact Disc–Re-Writable (CD-RW), Digital Video Disk–Read Only Memory (DVD-ROM), USB flash drives, etc.
[0112] The computer system 1000 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, or program logic that is combined with the computer system to make the computer system 1000 a special purpose machine or program the computer system 1000 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 1000 in response to the processor 1004 executing one or more sequences of one or more instructions contained in the main memory 1006. Such instructions may be read into the main memory 1006 from another storage medium, such as the storage device 1010. Execution of the sequences of instructions contained in the main memory 1006 causes the processor 1004 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.
[0113] The term "storage medium" as used herein refers to any non-transitory medium that stores data or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or flash drives, such as storage device 1010. Volatile media include dynamic memory, such as main memory 1006. Common forms of storage media include, for example, floppy disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges.
[0114] Storage media are distinct from transmission media, but can be used in conjunction with transmission media. Transmission media participate in the transmission of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 1002. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
[0115] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 1004 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1000 can receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector can receive the data carried in the infrared signal, and appropriate circuitry can place the data on the bus 1002. The bus 1002 carries the data to the main memory 1006, from which the processor 1004 retrieves and executes the instructions. The instructions received by the main memory 1006 may optionally be stored on the storage device 1010 before or after execution by the processor 1004.
[0116] Computer system 1000 also includes an interface circuit system 1018 coupled to bus 1002. Interface circuit system 1018 can be implemented by hardware according to any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) interface, Interface 1018 may be a processor, processor, or processor that is coupled to a processor and / or processors in a manner that is communicatively coupled to one or more discrete accelerators (eg, one or more XPUs).
[0117] Interface 1018 can also provide two-way data communication coupled to network link 1020, and network link 1020 is connected to local network 1022.For example, interface 1018 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem for providing a data communication connection to a telephone line of a corresponding type.As another example, interface 1018 can be a LAN card for providing a data communication connection to a compatible local area network (LAN).Wireless links can also be implemented.In any such implementation, interface 1018 can send and receive electrical, electromagnetic or optical signals carrying digital data streams representing various types of information.
[0118] The network link 1020 typically provides data communication through one or more networks to other data devices. For example, the network link 1020 may provide a connection to a host computer 1024 or to data equipment operated by an Internet Service Provider (ISP) 1026 through a local network 1022. The ISP 1026 in turn provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 1028. Both the local network 1022 and the Internet 1028 use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1020 and through the communication interface 1018 are example forms of transmission media that carry the digital data to and from the computer system 1000.
[0119] Computer system 1000 may send messages and receive data, including program code, through the network(s), network link 1020, and communication interface 1018. In the Internet example, server 1030 may transmit the requested code for an application program through Internet 1028, ISP 1026, local network 1022, and communication interface 1018. The received code may be executed by processor 1004 as it is received, or stored in storage device 1010 or other non-volatile storage for later execution.
[0120] Although many of the methods may be described herein in their basic form, it should be noted that processes may be added to or deleted from any of the methods, and information may be added to or subtracted from any of the described messages without departing from the basic scope of the current embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations may be made. The specific embodiments are not provided to limit the concepts but to illustrate the concepts. The scope of the embodiments is not determined by the specific examples provided above, but only by the claims below.
[0121] It should be appreciated that in the above description of exemplary embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various novel aspects. However, this method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than those expressly recited in each claim. On the contrary, as reflected in the appended claims, novel aspects reside in fewer features than all of the features of a single previously disclosed embodiment. Thus, the claims are hereby expressly incorporated into this specification, with each claim acting by itself as a separate embodiment.
[0122] The following clauses and / or examples refer to further embodiments or examples. Details in the examples may be used anywhere in one or more embodiments. Various features of different embodiments or examples may be combined in various ways with some features included and other features excluded to suit a variety of different applications. Examples may include subject matter such as: a method; an apparatus for performing the actions of the method; at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform the actions of the method; or an apparatus or system for facilitating the proposed DCI according to the embodiments and examples described herein.
[0123] Some embodiments relate to Example 1, which includes a non-transitory machine-readable medium storing instructions that, when executed by one or more processing resources of a computer system, cause the one or more processing resources to: determine whether to execute a non-containerized workload associated with a host application in the cloud or on a client computing system, the host application being run on the client computing system; and after determining that the non-containerized workload is to be executed on the client computing system: obtain an execution unit in which the non-containerized workload is encapsulated; and cause the non-containerized workload to run locally on the client computing system.
[0124] Example 2 includes the subject matter of Example 1, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system is performed by a migration recommendation engine represented in the form of a library consumed by the host application.
[0125] Example 3 includes the subject matter of example 1 or 2, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system is based at least in part on a static configuration of the client computing system.
[0126] Example 4 includes the subject matter of any of Examples 1-3, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system further includes: obtaining information about a dynamic state of the client computing system; and evaluating a migration strategy that defines conditions for permitting execution of the non-containerized workload on the client computing system relative to a static configuration and a dynamic state.
[0127] Example 5 includes the subject matter of any of Examples 1-4, wherein the migration policy is defined and managed in the cloud.
[0128] Example 6 includes the subject matter of any of Examples 1-4, wherein the migration policy is built into the host application for the non-containerized workload.
[0129] Example 7 includes the subject matter of any of Examples 1-6, wherein the host application comprises a web application executed within a browser of the client computing system, and the host application interacts with the non-containerized workload.
[0130] Example 8 includes the subject matter of any of Examples 1-6, wherein the host application comprises a native application developed for a specific operating system of the client computing system, and the host application interacts with the non-containerized workload.
[0131] Example 9 includes the subject matter of any of Examples 1-8, wherein the execution unit comprises a WebAssembly module or a machine learning (ML) model.
[0132] Some embodiments relate to Example 10, which includes a method comprising: determining whether to execute a non-containerized workload associated with a host application in the cloud or on a client computing system, the host application being run on the client computing system; and after determining that the non-containerized workload is to be executed on the client computing system: obtaining an execution unit in which the non-containerized workload is encapsulated; and causing the non-containerized workload to run locally on the client computing system.
[0133] Example 11 includes the subject matter of Example 10, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system is performed by a migration recommendation engine represented in the form of a library consumed by the host application.
[0134] Example 12 includes the subject matter of example 10 or 11, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system is based at least in part on a static configuration of the client computing system.
[0135] Example 13 includes the subject matter of any of Examples 10-12, wherein determining whether to execute the non-containerized workload in the cloud or on the client computing system further includes: obtaining information about a dynamic state of the client computing system; and evaluating a migration strategy that defines conditions for permitting execution of the non-containerized workload on the client computing system relative to a static configuration and a dynamic state.
[0136] Example 14 includes the subject matter of any of Examples 10-13, wherein the execution unit comprises a WebAssembly module or a machine learning (ML) model.
[0137] Example 15 includes the subject matter of any of Examples 10-14, further comprising: tracking metrics indicating cost savings accrued by a vendor of a host application due to execution of a non-containerized workload on a client computing system; and distributing at least a portion of the cost savings to one or both of subscribers of the host application and one or more third parties.
[0138] Example 16 includes the subject matter of any of Examples 10-15, wherein the distributing comprises providing a statement credit to the subscriber.
[0139] Example 17 includes the subject matter of any of Examples 10-16, wherein the distributing comprises causing the smart contract to pay the digital asset to one or both of the subscriber and one or more third parties.
[0140] Example 18 includes the subject matter of any of Examples 10-17, wherein the metric comprises a plurality of application programming interface (API) calls invoked by the host application.
[0141] Some embodiments relate to Example 19, which includes a method comprising: determining whether a specific workload associated with a host application is to be executed in the cloud or on a client computing system, the host application being run on the client computing system; after determining that the specific workload is to be executed on the client computing system: obtaining an execution unit in which the specific workload is encapsulated; and causing the specific workload to run locally on the client computing system; causing metrics indicating usage of resources of the cloud by the host application within a specific time frame to be tracked by a telemetry service; estimating cost savings accrued by a provider of the host application within the specific time frame based on the metrics; and distributing at least a portion of the cost savings to one or both of subscribers of the host application and one or more third parties.
[0142] Example 20 includes the subject matter of Example 19, wherein the execution unit comprises a non-containerized workload or a containerized workload.
[0143] Some embodiments relate to Example 21, which includes an apparatus or system that implements or performs a method as in any of Examples 10-20.
[0144] Example 22 includes at least one machine-readable medium including a plurality of instructions that, when executed on a computing device, implement or perform the method described in any of the preceding examples or implement the apparatus described in any of the preceding examples.
[0145] Example 23 includes an apparatus or system comprising means for performing the method as described in any of Examples 10-20.
[0146] The accompanying drawings and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the elements described can be well combined into a single functional element. Alternatively, certain elements can be split into multiple functional elements. Elements from one embodiment can be added to another embodiment. For example, the order of the processes described herein can be changed, and the order of the processes described herein is not limited to the methods described herein. Moreover, the actions of any flow chart do not have to be implemented in the order shown; it is not necessary to perform all these actions. In addition, those actions that are independent of other actions can also be performed in parallel with other actions. The scope of each embodiment is by no means limited by these specific examples. Numerous variants (whether or not explicitly given in the specification) are possible, such as differences in the use of structure, scale and material. The scope of the embodiment is at least as wide as the scope given by the appended claims.
Claims
1. A non-transitory machine-readable medium storing instructions that, when executed by one or more processing resources of a computer system, cause the one or more processing resources to: determining whether to execute a non-containerized workload associated with a host application in the cloud or on a client computing system on which the host application is running; and After determining that the non-containerized workload is to be executed on the client computing system: obtaining an execution unit in which the non-containerized workload is encapsulated; and The non-containerized workload is caused to run locally on the client computing system.
2. The non-transitory machine-readable medium of claim 1, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is performed by a migration recommendation engine represented in the form of a library consumed by the host application.
3. The non-transitory machine-readable medium of claim 1, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is based at least in part on a static configuration of the client computing system.
4. The non-transitory machine-readable medium of claim 3, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system further comprises: obtaining information about a dynamic state of the client computing system; and A migration policy is evaluated that defines conditions for permitting execution of the non-containerized workload on the client computing system relative to the static configuration and the dynamic state.
5. The non-transitory machine-readable medium of claim 4, wherein: The migration strategy is defined and managed in the cloud.
6. The non-transitory machine-readable medium of claim 4, wherein: The migration policy is built into the host application for the non-containerized workload.
7. The non-transitory machine-readable medium of any one of claims 1 to 6, wherein: The host application comprises a web application executing within a browser of the client computing system, and the host application interacts with the non-containerized workload.
8. The non-transitory machine-readable medium of any one of claims 1 to 6, wherein: The host application includes a native application developed for a specific operating system of the client computing system, and the host application interacts with the non-containerized workload.
9. The non-transitory machine-readable medium of any one of claims 1 to 6, wherein: The execution unit includes a WebAssembly module or a machine learning (ML) model.
10. A method comprising: determining whether to execute a non-containerized workload associated with a host application in the cloud or on a client computing system, the host application being executed on the client computing system; as well as After determining that the non-containerized workload is to be executed on the client computing system: obtaining an execution unit in which the non-containerized workload is encapsulated; and The non-containerized workload is caused to run locally on the client computing system.
11. The method of claim 10, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is performed by a migration recommendation engine represented in the form of a library consumed by the host application.
12. The method of claim 10, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is based at least in part on a static configuration of the client computing system.
13. The method of claim 12, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system further comprises: obtaining information about a dynamic state of the client computing system; and A migration policy is evaluated that defines conditions for permitting execution of the non-containerized workload on the client computing system relative to the static configuration and the dynamic state.
14. The method according to any one of claims 10 to 13, wherein: The execution unit includes a WebAssembly module or a machine learning (ML) model.
15. The method of any one of claims 10 to 13, further comprising: tracking a metric indicative of cost savings accrued by a vendor of the host application due to execution of the non-containerized workload on the client computing system; as well as At least a portion of the cost savings is distributed to one or both of subscribers of the host application and one or more third parties.
16. The method according to any one of claims 10 to 13, wherein: The distributing includes providing a statement credit to the subscriber.
17. The method according to any one of claims 10 to 13, wherein: The distribution includes causing the smart contract to pay the digital asset to one or both of the subscriber and one or more third parties.
18. The method according to any one of claims 10 to 13, wherein: The metrics include a plurality of application programming interface (API) calls invoked by the host application.
19. A computer system for migrating a user session from a cloud instance to a client device, the computer system comprising: one or more processors; as well as a memory coupled to the one or more processors, the memory being configured to store instructions that, when executed by the one or more processors, cause the one or more processors to: determining whether to execute a non-containerized workload associated with a host application in the cloud or on a client computing system on which the host application is running; and After determining that the non-containerized workload is to be executed on the client computing system: obtaining an execution unit in which the non-containerized workload is encapsulated; and The non-containerized workload is caused to run locally on the client computing system.
20. The computer system of claim 19, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is performed by a migration recommendation engine represented in the form of a library consumed by the host application.
21. The computer system of claim 19, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system is based at least in part on a static configuration of the client computing system.
22. The computer system of claim 21, wherein: Determining whether to execute the non-containerized workload in the cloud or on the client computing system further comprises: obtaining information about a dynamic state of the client computing system; and A migration policy is evaluated that defines conditions for permitting execution of the non-containerized workload on the client computing system relative to the static configuration and the dynamic state.
23. The computer system of any one of claims 19 to 22, wherein: The host application comprises a web application executing within a browser of the client computing system, and the host application interacts with the non-containerized workload.
24. The computer system of any one of claims 19 to 22, wherein: The host application includes a native application developed for a specific operating system of the client computing system, and the host application interacts with the non-containerized workload.
25. The computer system of any one of claims 19-22, wherein: The execution unit includes a WebAssembly module or a machine learning (ML) model.