Methods and systems may be associated with an Open Service Broker (“OSB”) Application Programming Interface (“API”) computing environment. A serverless runtime may receive an OSB request trigger from an API gateway. A serverless deployment mechanism may, responsive to the OSB request trigger, arrange for compute resources to handle the OSB request trigger be provisioned on-demand. The system may then instantiate an instance of a serverless function with OSB service bindings. The OSB API computing environment might, for example, be associated with a cloud infrastructure provider or an on-premises deployment. Such an approach may provide for on-demand execution, better resource constraints, and/or domain-oriented development.

An improved method for managing multi-cloud spot markets for executing a computing job is disclosed. Multiple clouds may be searched automatically for available spot instances by stepping through different available instance types based on job requirements. The results may be sorted and filtered, and one or more preferred instance types may be selected from the sorted and filtered results. The computing job may be automatically deployed to the selected instance types. If the selected spot instance is no longer available, an alternate instance may be suggested. Redundant deployment to different instance types on the same or different clouds may be enabled, and machine learning may be used to predict future availability of instance types.

A quantum computing service includes a quality of service (QoS) and out-of-band prioritization module. The QoS and out-of-band prioritization module enforces QoS guarantees for quantum tasks and quantum jobs submitted to the quantum computing service while allowing for processing of the quantum jobs and quantum tasks based on QoS guarantees and not necessarily in an order in which the quantum jobs or quantum tasks are received. Also, the QoS and out-of-band prioritization module determines updated priorities out-of-band based on quantum resource usage information for previously executed quantum tasks such that submittal of pending quantum tasks is not delayed in while update priorities are being determined.

An approach for estimating future cloud resource requests. The approach receives information defining a present budget interval. The approach analyzes a cloud resource request database based on entry times in respective past budget intervals occurring within a remaining time in the present budget interval. The approach creates estimates of future expected cloud resource requests based on the analysis.

At a network-accessible service, a request is received from a client to enable access by a migration facilitator to a configuration record collection of the client. A response to a migration candidate identification query is generated using the configuration record collection and transmitted to the facilitator. An indication of a proposal associated with migrating at least a portion of the client's computing environment to a different computing environment with assistance from the facilitator is provided to the client.

Methods, systems, and computer-readable storage media for receiving, by a cross-process scheduling engine executed within a cloud platform, work scenario metadata and sensitivity metadata, generating, by the cross-process scheduling engine, a lineage graph representing relationships between one or more of data and processes to be executed for a work scenario represented by the work scenario metadata, defining, by the cross-process scheduling engine, a set of tile segments for the work scenario based on the lineage graph and the sensitivity metadata, dispatching, by the cross-process scheduling engine, a first sub-set of tile segments for execution in a private deployment including one or more private nodes, and dispatching, by the cross-process scheduling engine, a second sub-set of tile segments for execution in a public deployment including one or more public nodes.

A database management system receives a user request for provisioning a database, autonomously selects a datacenter for provisioning the database based at least on a first pre-defined rule, autonomously selects at least one cluster in the datacenter based at least on a second pre-defined rule, determines a network location of each of the at least one cluster, and provisions the database on each of the at least one cluster using the network location of each of the at least one cluster.

Autonomous management of resources by an administrative node network is disclosed, including: receiving, at a first node of a plurality of nodes associated with an administrative node network, a resource request directed to the administrative node network, wherein the administrative node network is associated with managing a set of resources; obtaining a first proposal with respect to the resource request; obtaining a second proposal with respect to the resource request from a second node of the plurality of nodes associated with the administrative node network; and determining a processing consensus associated with the resource request based at least in part on the first proposal and the second proposal.

This application discloses a decentralization processing method, which are applied to a microservice system. A first communication proxy in the microservice system receives a first microservice request sent by a first microservice application, the first communication proxy determines, based on a target control plane rule, a microservice access address corresponding to the first microservice request, and sends the first microservice request to the second communication proxy having the microservice access address, where the second communication proxy is used to forward the first microservice request to the second microservice application. The first communication proxy can send the microservice request to the corresponding second communication proxy, and a control plane does not need to route the microservice request, so that traffic for routing the microservice request by the control plane is effectively reduced, and impact of a burst of microservice requests on the control plane is effectively avoided.

In an approach for balancing mainframe and distributed workloads, a processor receives a request to allocate an application workload to a mainframe platform and a distributed computing platform. The application workload includes a plurality of work units. A processor collects performance and cost data associated with the application workload, the mainframe platform, and the distributed computing platform. A processor determines the mainframe platform and the distributed computing platform for the plurality of work units of the application workload, based on the analysis of the performance and cost data. A processor allocates the plurality of work units of the application workload to run on the mainframe platform and the distributed computing platform respectively to balance performance and cost in real time.