WO2016195716A1 - Price, completion time, and resource allocation determination for cloud services - Google Patents

Abstract

Techniques are provided for price, completion time, and resource allocation determination for cloud services. A system for the same can include a request engine to continuously receive requests for cloud services from a plurality of users of a cloud system and an input engine to receive a plurality of parameters relating to the requested cloud services from at least one of each of the plurality of users and a provider of the cloud system. The system can include an output engine to determine a plurality of variables relating to each of the requested cloud services using the plurality of parameters and a mixed integer programming solver and a menu engine to generate a cloud service menu in response to each of the continuously received requests to be offered to the plurality of users, the cloud service menu defining prices, and associated completion times for each of the requested cloud services.

Description

PRICE, COMPLETION TIME, AND RESOURCE ALLOCATION DETERMINATION FOR CLOUD SERVICES

Background

[0001] The cloud refers to hardware and software resources available across the Internet. Companies that offer these resources are referred to as Cloud Service Providers (CSP). Cloud services can be roughly categorized as Infrastructure-as-a-Service (laaS), Platform-as-a-Service (PaaS) and Software- as-a-Service (SaaS). This categorization is based on the complexity of the service, from raw compute resources, such as storage or processing power, to refined software services, such as databases or other applications.

Brief Description of the Drawings

[0002] Figure 1 illustrates an example system for price, completion time, and resource allocation determination for cloud services according to the present disclosure.

[0003] Figure 2 illustrates a diagram of an example computing device according to the present disclosure.

[0004] Figure 3 illustrates a diagram of an example system for price, completion time, and resource allocation determination for cloud services according to the present disclosure.

[0005] Figure 4 illustrates an example menu for pricing of cloud resources according to the present disclosure.

[0006] Figure 5 illustrates an example flow chart of a method for price, completion time, and resource allocation determination for cloud services according to the present disclosure. Detailed Description

[0007] The cloud computing model allows users (e.g., customers) to rent computing infrastructure as needed, rather than having to purchase their own resources. Moreover, customers can increase or decrease the size of their cloud resources in a straightforward and timely manner, depending on their computing conditions and/or cloud services needed by the user. Cloud services may be sold according to an instance-based model. In an instance-based model, the customer may rent the instances needed to complete a particular job. As used herein, an "instance" refers generally to an isolated user space instance, which can be executed within a virtualized environment (e.g., a "cloud"). Other technologies aside from hardware virtualization can provide isolated user space instances, also referred to as data compute nodes. Data compute nodes may include non-virtualized physical hosts, virtual machines (VMs), containers that run on top of a host operating system without a hypervisor or separate operating system, and/or hypervisor kernel network interface modules, among others.

[0008] A batch application, herein referred to as a "service" a "job", or a "cloud service", may require the usage of resources such as virtual servers or nodes. A cloud service may be a deployable unit comprised of one or more job steps. Examples of a cloud service include a Monte Carlo simulation, an optimization problem, and a data mining job, among others. A cloud service may be a single, well-defined job that includes a plurality of processes to be completed. A cloud service may include a series of closely related processing steps that, taken together, perform a particular process and/or processes.

[0009] In the instance-based model, a cloud provider may rent out nodes, servers, and/or VMs. However, such models are resource-based and the customer may have to define the number and type of cloud resources that are needed to perform a given service, as well as for how long they are needed. Knowing exactly how many, which kind, and how long cloud resources are needed may require a level of technical expertise that the customer may not have. As a consequence, customers may over-provision cloud resources, meaning that the customer may purchase cloud resources that aren't needed and/or aren't used. Further, customers may experience difficulty predicting how many and what type of nodes they need for a particular job, due to a variety of factors. One example is the interference generated in the cloud system by a plurality of services run simultaneously. Given that the cloud provider controls which services are run in the cloud at any point of time, it may be more efficient for a cloud provider to determine how many and what type of cloud resources are used to complete a particular job by a given time.

[0010] Furthermore, multiple arrangements of cloud resource allocation may be possible which may be beneficial for the customer and/or the cloud provider. A customer may specify a number, type, and duration of cloud resources needed to complete a job, specified in nodes per unit time. For example, the customer may specify that 10 nodes of a particular type are needed for 3 hours. Furthermore, the customer may pay a price for the 10 nodes for 3 hours. However, from the cloud providers' perspective, there may be benefits to allocating the cloud resources in another manner. For instance, the cloud provider may wish to perform a particular job in a short amount of time with a greater number of nodes, or to perform the job in a greater amount of time with a fewer number of nodes in order to server other, more remunerative customers. In such a manner, the cloud provider may provide the client with a variety of pricing options for performing and completing a particular job by different times.

[0011] Moreover, a cloud service provider may have limited resources. The cloud service provider may face a set of potential customers requesting different services. Each service may be described in terms of arrival time (also referred to as earliest start time) and total resource cost. The total resource cost, as used herein, refers to the number of resources that are needed to complete the service (e.g., in node-periods). It may depend on the application and the data that constitutes the service. The number of resources assigned over time to a job affects the speed at which the job is completed. The service provider may choose how to assign resources to the service over time in order to satisfy the total resource cost condition. Furthermore, each potential customer may be willing to pay different amounts of money if the service requested is completed within different time intervals (e.g. 1 -3 hours, 1 -12 hours...).

[0012] In addition, online scheduling of services may pose challenges for a cloud service provider. For instance, requests from customers may arrive at the cloud service provider continuously (e.g., sequentially). Put another way, the requests are received dynamically. As used herein, continuously receiving requests refers to receiving requests by the cloud service provider while the cloud service provider is using resources. At each point in time, the cloud service provider receives different requests to execute jobs. As used herein, dynamically receiving requests refers to the cloud service receiving requests in a usually continuous, productive, or changing manner. In such instances, certain nodes in the cloud service may be in use, meaning an incoming request may not be fulfilled using that occupied node.

[0013] Price and completion time determination in the cloud context may be subject to three or more sources of uncertainty: uncertainty about the customers' willingness to pay for various cloud services; uncertainty about a sequence of requests that will arrive over time; and uncertainty about total resource cost and/or demand associated with each service. The service provider may desire to profit by selling a menu of different service-specific guaranteed completion-times. The service provider may decide which items to include in the menu, how to price each item in the menu, and how to allocate resources in order to deliver the services sold according to the agreed completion-times, among other considerations. As discussed further herein, examples of the present disclosure may include systems, methods, and machine-readable and executable instructions and/or logic.

[0014] Completion-time based price and completion time determination of cloud services in accordance with the present disclosure provides a model by which a cloud provider may sell cloud services in a results-based system, rather renting out nodes, servers, and/or VMs (as with the instance-based model). As used herein, a completion-time based price refers to a price for a particular cloud service that is based on an identified completion-time for the particular cloud service. Instead of charging per resources, the cloud provider may charge the customer by output such as a completion time of the cloud services that are requested.

[0015] Examples of the present disclosure consider online scheduling, such that all request for jobs are not collected ex-ante. Prices are not determined at a time when the cloud provide holds the same information about all of them. Rather, examples of the present disclosure include dynamically set prices. As used herein, dynamically set prices refers to a cloud provider selecting new prices on the basis of past jobs about which the provider has learned.

[0016] Further, examples of the present disclosure consider online pricing and scheduling in the context of a revenue-maximizing seller of output-based quality of service (QoS). This is in contrast to completion time-based allocation approaches that attempt to maximize efficiency without any uncertainty regarding a job's resource conditions and values. In some examples, profit may be maximized, as well, by considering a cost of servicing a job or jobs.

[0017] Additionally, in contrast to approaches that include competition between contenders that simultaneously advance their requests for some scarce resource, examples of the present disclosure do not include the presence of simultaneous competitors. Rather, examples of the present disclosure include a menu of different prices directed exclusively to one potential customer.

[0018] Determination of completion-time based prices and completion time determination of cloud services according to the present disclosure allows a practical implementation of the sale of performance-based cloud services. Examples of the present disclosure allow the cloud service provider to expand the market to segments of less tech-savvy customers. Moreover, determination of completion-time based price and completion time of cloud services according to the present disclosure introduces a new dimension (i.e. service performance quality levels) over which the provider can price-discriminate potential customers and therefore, under certain conditions, may increase profits.

Further, while the foregoing disclosure generally refers to a "customer" and a "user" interchangeably, it is noted that a "customer" may be either an internal customer or an external customer. Put another way, the cloud services may be offered to users within the same company and/or organization as the cloud service provider. In such examples, an objective function (described further herein) may be to increase benefits of the cloud services derived by the users within the company and/or organization.

[0019] The interaction between each customer and the cloud resource provider in any period t^* may include the following. At time t^*, a number of jobs j are submitted for execution. For instance, these are request for which the earliest start time is t^*. Once a job is submitted, the cloud provider discovers its requirements (expressed in node-periods). Given this information and the available resources at time t^*, the cloud provider sets the menu of prices for the job, indexed by completion time.

[0020] Given the menu and customers' willingness to pay for each completion time, customers who submitted jobs j with arrival time t^* decide whether to select an item from the menu and sign a contract with the cloud provider. For instance, if the customer chooses one item in the menu, the provider commits to completing the job within the associated number of periods, and revenue for the job is realized according to the price of the menu item. At this stage, the resource allocation for all jobs j that are in process in t^* are determined. If the customer submitting a job j chooses nothing, no revenue is realized and no resources are allocated.

[0021] Figure 1 illustrates an example system 100 for price, completion time, and resource allocation determination for cloud services according to the present disclosure. The system 100 may include a database 101 , a subsystem 102, and/or a number of engines (e.g., request engine 103, input engine 104, and output engine 105, and menu engine 106). As used herein, "a" or "a number of something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. The subsystem may include the number of engines in communication with the database 101 via a communication link. The system 100 may include additional or fewer engines than illustrated to perform the various functions described herein. The system may represent software and/or hardware of a network controller (e.g., device 208 as referenced in Figure 2, etc.).

[0022] The number of engines may include a combination of hardware and programming that is configured to perform a number of functions described herein (e.g., receive cloud service requests online from a plurality of users of a cloud system, etc.). The programming may include program instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., computer readable medium (CRM), machine readable medium (MRM), etc.) as well as hard-wired program (e.g., logic).

[0023] The request engine 103 may include a combination of hardware and programming that is configured to continuously receive (online) requests for cloud services from a plurality of users of a cloud system. As used herein, a cloud service request received online refers to a cloud service request that is submitted while other jobs are running/executing on the cloud service. In the foregoing examples, "time" is considered a sequence of discrete intervals (e.g. minutes, hours, days, ...) during execution of jobs. At each time, new

information may become available, and the price and resource allocation system may re-optimize. For instance, information learned from previous requests and services (e.g., new information about jobs and customers) may become available.

[0024] Given that, a set of time periods T = {1 , ...,T} may be considered. The last period T may define the horizon length over which the price and resource allocation system (e.g., optimization) is applied. The extension of such horizon may be determined by external factors (e.g. there is a general system reset every 24 hours) or may be selected arbitrarily by the service provider. As time progresses and the price and resource allocation system re-optimizes, the horizon length may vary. In other words, T may be updated to a new value T.

[0025] The input engine 104 may include a combination of hardware and programming that is configured to receive a plurality of parameters relating to the requested cloud services from at least one of each of the plurality of users and a provider of the cloud system. Put another way, the user (e.g., customer) may provide parameters, the cloud service provider may provide parameters, or both the user and cloud service provider may provide parameters.

[0026] As used herein, a parameter refers to an input that has a known value. An example of a parameter may be the earliest period in which the job, represented by j, can start and/or arrives, the parameter represented by s(j). The value of s(j) may correspond to the job j's arrival time or to the earliest time the job j may begin. Another example of a parameter may be the total number of node-periods that the job j may use for completion if the job j is of a particular type (e.g., type h), the parameter represented by r(j,h). Yet another example of a parameter may be (an estimate of) of a customers' willingness-to-pay level for the job j to be completed within an elapsed time d after s(j) if the customer requesting job j is of a particular type (e.g., type k), the parameter represented by w(j,k,d). Put another way, the cloud service provider may make particular assumptions about the customer k's willingness to pay for job j during duration d. Other examples of parameters include: (}, h) , the probability that job j is of type h, and k), the probability that job j's customer is of type k.

[0027] In some examples, parameters j, s(j), and r(j,h) come from the user, while other variables are provided by the cloud provider. Embodiments are not so limited, however. Additionally, in some examples, the timing according to which the parameters are entered may differ. Parameters provided (e.g., entered) by the cloud provider are provided before any price pQ,d) is offered. An engine may be pre-set up with these provider-provided parameters.

[0028] The output engine 105 may include a combination of hardware and programming that is configured to determine a plurality of variables relating to each of the requested cloud services using the plurality of parameters and a mixed integer programming solver. In an example, a variable among the plurality of variables may include a number of resources to be allocated. As used herein, a mixed integer programming solver refers to hardware and programming that is configured to solve an optimization problem in which some or all of the variables are discrete integers, and some of the variables are allowed to be non-integers. Examples of mixed integer programming solvers may include CPLEX^® and/or Gurobi^®. However, examples are not so limited, and the system 100 may be implemented with a different mixed integer programming solver than those described. Discrete integers may include binary variables 0 and 1 , whereas non-integers may include all numerical values for example, 0, 1 , 2.5, 4.1 , etc.

[0029] In some examples, the output engine 105 may include a combination of hardware and programming that is configured to assign a plurality of resources to each of a plurality of cloud service requests during a plurality of time periods. For instance, a first cloud service request may be received from a first user, and a second cloud service request may be received from a second user. Both the first cloud service request and the second cloud service request may include an arrival time/earliest possible start time s(j). As such, the output engine may assign a plurality of resources within the cloud system to each of the first and second cloud service requests, such that each of the first and second cloud service requests may be completed.

[0030] A variable may refer to an endogenous variable that may be determined from the system 100. As discussed further in relation to Figure 3, examples of variables may include an integer number of nodes, a maximum number of servers, a binary variable indicating if a particular service request having a particular cost type and customer type is completed at a particular time, a binary variable indicating if a service request having a particular cost type and customer type is completed with a particular elapsed time, a revenue earned for a particular service request, and a price offered for a particular service request (e.g., for completion of job j), among other variables. For example, based on the parameters received, either from the user or the cloud service provider, x(j,h,k,t) may be determined, the integer number of nodes assigned to job j of cost type h at time t for customer type k. Furthermore, based on the parameters received, p(j,d) may be determined, the price offered for completion of job j during d periods after the job's arrival. In such a manner, a plurality of pricing options may be determined for various completion times of the job.

[0031] The menu engine 106 may include a combination of hardware and programming that is configured to generate a cloud service menu in response to each of the continuously received requests to be offered to the plurality of users, the cloud service menu defining prices and associated completion times for each of the requested cloud services. In some examples, prices are per- resource-period prices. Based on the values of the variables determined, various menu options may be provided to the user. For instance, the menu engine 106 may generate a menu having three prices listed to complete a requested cloud service: a first price (e.g., lowest) that has a first completion time (e.g., the latest completion time), a second price (e.g., intermediate) that has a second completion time (e.g., an intermediate completion time), and a third price (e.g., the highest) that has a third completion time (e.g., the earliest completion time). Example menus are discussed further herein with respect to Figure 4. Examples are not so limited, however, and the cloud service menu may include more or fewer pricing and completion time options than described herein. For instance, the cloud service provider may offer no menu at all to some cloud service requests, or only one (1 ) menu item to some cloud service requests. Put another way, the cloud service menu may differ from one cloud service request to the next.

[0032] Furthermore, the system 100 may include a selection engine (not illustrated in Figure 1 ). The selection engine may include a combination of hardware and programming that is configured to receive and/or record a user's selection of a particular menu item, and execute jobs according to the selected menu item. For example, if a user among the plurality of users of the cloud system purchased a particular pricing option for a requested cloud service, resources in the cloud system may be allocated to specifically perform that requested cloud service within the agreed upon completion time and for the agreed upon price reflected in the cloud menu. In some examples, the selection engine may also determine that, if the user has not selected any item for a certain time, all menu items may be considered as rejected.

[0033] Furthermore, the system 100 may include an optimization engine (not illustrated in Figure 1 ). In some examples, the output engine 105 may perform the functions of the optimization engine. For instance, to determine variables (i.e. the output), an optimization problem may be solved. The optimization engine may include a combination of hardware and programming that is configured to dynamically optimize the prices and the associated completion times as new requests for cloud services are received. As used herein, dynamic optimization refers to adjusting offers of pricing and completion time as new information is obtained and/or learned. For instance, as new customer and job information is received in a dynamic (e.g., continuous, productive, changing, etc.) manner, offers pricing and completion time offers may change to better maximize profits and/or efficiency.

[0034] Figure 2 illustrates a diagram of an example computing device 208 according to the present disclosure. The computing device 208 may utilize software, hardware, firmware, and/or logic to perform a number of functions described herein. The computing device 208 may be any combination of hardware and program instructions configured to share information. The hardware, for example, may include a processing resource 209 and/or a memory resource 21 1 (e.g., CRM, MRM, database, etc.). A processing resource 209, as used herein, may include any number of processors capable of executing instructions stored by a memory resource 21 1 . Processing resource 209 may be implemented in a single device or distributed across multiple devices. The program instructions (e.g., computer readable instructions (CRI)) may include instructions stored on the memory resource 21 1 and executable by the processing resource 209 to implement a desired function (e.g., receive a request for a cloud service from a user of a cloud system). While Figure 2 generally illustrates a single computing device 208, examples are not so limited. For instance, the system 100 (described in Figure 1 ) may be implemented on a plurality of computing devices, such that each engine described in Figure 1 and each module described in Figure 2 may be executed by one or more computing devices.

[0035] The memory resource 21 1 may be in communication with a processing resource 209. A memory resource 21 1 , as used herein, may include any number of memory components capable of storing instructions that may be executed by processing resource 209. Such memory resource 21 1 may be a non-transitory CRM or MRM. Memory resource 21 1 may be integrated in a single device or distributed across multiple devices. Further, memory resource 21 1 may be fully or partially integrated in the same device as processing resource 209 or it may be separate but accessible to that device and processing resource 209. Thus, it is noted that the computing device 208 may be implemented on a participant device, on a server device, on a collection of server devices, and/or a combination of the user device and the server device.

[0036] The memory resource 21 1 may be in communication with the processing resource 209 via a communication link (e.g., a path) 210. The communication link 210 may be local or remote to a machine (e.g., a computing device) associated with the processing resource 209. Examples of a local communication link 210 may include an electronic bus internal to a machine (e.g., a computing device) where the memory resource 21 1 is one of volatile, non-volatile, fixed, and/or removable storage medium in communication with the processing resource 209 via the electronic bus.

[0037] A number of modules (e.g., request module 213, input module 214, output module 215, pricing module 216, and resource allocation module 218) may include CRI that when executed by the processing resource 209 may perform a number of functions. The number of modules may be sub-modules of other modules. For example, the request module, the input module, and the output module can be sub-modules and/or contained within the same computing device. In another example, the number of modules can comprise individual modules at separate and distinct locations (e.g., CRM, etc.).

[0038] Each of the number of modules may include instructions that when executed by the processing resource 209 may function as a corresponding engine as described herein. For example, the request module 213 may include instructions that when executed by the processing resource 209 may function as the request engine 103. In another example, the input module 214 may include instructions that when executed by the processing resource 209 may function as the input engine 104. Additionally, the output module 215 may include instructions that when executed by the processing resource 209 may function as the output engine 105. [0039] The request module 213 may include instructions that when executed by the processing resource 209, may continuously receive from a plurality of users of a cloud system, a plurality of cloud service requests. As described in relation to Figure 1 , cloud service requests may come in continuously, and may be received from a single user of the cloud system or from a plurality of users of the cloud system.

[0040] The input module 214 may include instructions that when executed by the processing resource 209, may receive parameters relating to the requested cloud service from at least one of the user and a provider of the cloud system. As previously noted, some parameters may be provided by the user, while others are provided by the cloud provider. Similarly, the output module 215 may include instructions that when executed by the processing resource 209, may determine a plurality of variables relating to the requested cloud services using the plurality of parameters and a mixed integer

programming solver, as discussed in relation to Figure 1 . The input module 214 and/or the output module 215 may include instructions that when executed by the processing resource 209 may determine resources in the cloud system to be allocated to a subset of the requested cloud service requests.

[0041] In some examples, the computing device 208 may further include a menu module (not illustrated in Figure 2) that when executed by the processing resource 209 may generate a cloud service menu to be offered to the user, the cloud service menu defining a price and a completion time for the requested cloud service.

[0042] The pricing module 216 may include instructions that when executed by the processing resource 209 may provide a plurality of pricing options to each user for completion of the plurality of cloud service requests using the determined total resource cost, a completion time, expectations about future service requests, and information gathered from previously provided pricing options. For instance, depending on successes and/or failures (e.g., acceptance and/or rejections) of offers in the past, pricing determinations may be made and provided, and adjustment of parameters may be suggested (e.g., increasing/decreasing expected willingness to pay levels or changing probabilities). In some examples, the pricing module 216 may provide a pricing option to a subset of the plurality of users for completion of a subset of the plurality of cloud service requests. Furthermore, the resource allocation module 218 may include instructions that when executed by the processing resource 209 may assign resources in the cloud system to each of the cloud service requests. The resource allocation module 218 may allocate resources in the cloud system to fulfill a user selected pricing option from among the pricing options provided in the cloud service menu.

[0043] In some examples, the computing device 208 may further include instructions that when executed by the processing resource 209 may identify a job type for each cloud service request received from users of the cloud system, and identify a total number of node periods to complete (e.g., required to complete) each of the cloud service requests based on the determined job type and size. For example, a Monte Carlo simulation may use a different number of node periods as compared to an optimization problem. As discussed in relation to Figure 3, the computing device 208 may include instructions to receive a probability that a cloud service request is received from a particular customer type. Based on the determined information, such as customer type, job type, cost type, etc., beliefs about future service requests, using a plurality of constraints and/or rules, and considering information gathered from previous offers (e.g., customer and job information) as discussed further, a price, completion time and resource allocation in the cloud system may be determined to maximize the revenue received (by the cloud service provider) from the plurality of cloud service requests.

[0044] Figure 3 illustrates a diagram of an example system 320 for price, completion time, and resource allocation determination for cloud services according to the present disclosure. As illustrated in Figure 3, the system 320 may include a cloud service manager 321 , a mixed integer programming solver 322, and a plurality of cloud resources 323-1 , 323-N (collectively referred to as resources 323). In a number of examples, resources 323 may be

substitutable and may be homogeneous. As described herein, a cloud resource refers to a virtual or physical component in a cloud system. Examples of cloud resources may include VMs, virtual servers, physical servers, and/or nodes among other resources. Cloud resources may be exclusive, in that at each point of time, each resource can be applied only to one service. Furthermore, cloud resources may be re-usable in that past usage of a particular cloud resource does not affect future usability of the cloud resource. Additionally, cloud resources may be mobile in that a cloud resource that was utilized for a first service at one point of time may be reallocated to a second service at a second (e.g., subsequent) point of time. Moreover, cloud resources (e.g., node- periods) may be non-perishable in that they do not expire after a certain time.

[0045] The cloud service manager 321 may deploy and manage cloud services. For instance, the cloud service manager 321 may receive requests online for cloud services from a plurality of users 324-1 ,..., 324-P (e.g., customers) of a cloud system. Put another way, requests for cloud services j may be collected continuously by the cloud service. Each service request may also be referred to as a "job". Because of the continuous, online nature of the collection, a full set of jobs may not be known; rather sets of jobs develop dynamically. Each job may be indexed by j, and the set of jobs may be represented by J = {1 ,...,J}. Each job may be identified by one unique time at which the job is submitted. Two jobs that differ only in terms of their submission times may be assigned different indexes j. In other examples, multiple jobs may arrive at the same time. Set J may change over time. Each job served may be assigned a number of resources (e.g., node-periods) in possibly multiple time periods until completion. Put another way, cloud service manager 321 may determine a plurality of resources 323 for each cloud service request. Because both sets J and T may change over time, uncertainty about the sequence (and nature) of jobs that will arrive over time may be managed. Each job j e J may have the characteristic s(j): the earliest period in which the job j can start. This may correspond to the job's arrival time or submission.

[0046] Each service request (e.g., job) may be interpreted as coming from a customer with different willingness to pay for the particular job to be completed by different times. This willingness to pay may be the customer's private information. A belief of the cloud provider over each customer's willingness to pay may be represented by a probability distribution over different types of customers. The set of customer types may be defined by K = {1 , ..., K}. For instance, different job and customer type combinations (j,k) may have the following characteristics:

Tt(j, k): the probability that job j's customer is of type k. Note that

∑_k Tt(j, k) = 1 for each j.

w(j,k,d): A customer of type k's willingness to pay for job j if it is completed during d periods after arrival time s(j). No restrictions are imposed on a relation between job types h and customer types k.

[0047] As discussed previously herein, the total number of node-periods or resources needed to complete a particular job may be determined. The nodes may be homogeneous, and the total number of available nodes and/or resources for the cloud service provider may be represented by N. In some examples, N may change over time.

[0048] Each job may have a horizon length. As used herein, the horizon length refers to the latest possible completion duration for job j that would result in revenue for the cloud provider. The horizon length may be determined using the following: m(j) = maxk {max{d: w(j,k,d)>0}}. The inner maximization represents the maximum value for d for which w(j,k,d) is positive. The outer maximization represents the maximum over k of the inner max value. In some examples, the overall horizon length may be represented by T = maxj {s(j) + m(j)} to ensure enough time in the horizon to complete every job received from the users 324. Also, for each job j, l(j) may be the minimum number of periods that may be required to complete the job (if all N nodes are assigned to the request). The inner maximization represents the maximum value for d for which w(j,k,d) is positive. The outer maximization represents the maximum over k of the inner max value.

[0049] The cloud service manager 321 may receive a plurality of cloud service requests from users 324. The cloud service manager 321 may determine a full list of cloud service requests from the plurality of users 324 of the cloud system. Based on the full list of cloud service requests received and beliefs about future cloud services submissions, the cloud service manager 321 may determine a plurality of resources 323 for each cloud service request received.

[0050] Based on the cloud service requests received from the users 324, the cloud service manager 321 may determine a plurality of variables based on job type and customer type. For instance, the following variables may be determined:

x(j,h,k,t): integer number of nodes assigned to job j of cost type h at time t for customer type k. This may be defined for t such that s(j) < t < s(j) + mO - 1 .

g(j,t): maximum number of servers allocated to job j in time t over all customer types k and cost types h. This may be defined for all j and for t such that s(j) < t < s(j) + m(j) - 1 .

y(j,h,k,t): binary variable indicating if job j of cost type h completes at time t for customer type k. This may be defined for t such that

sG)≤t≤sG) + mG) - 1 .

u(j,h,k,d): binary variable indicating if job j of cost type h completes with elapsed time d from arrival time earliest start time s(j) for customer type k. This may be defined for d such that 0 < d < m(j).

v(j,h,k,d): revenue earned for job j of cost type h during d periods after the job's arrival for customer type k. u(j,h,k,d) and may be defined for d such that 0 < d < m(j).

p(j,d): price offered for completion of job j during d periods after s(j). This may be defined for d such 0 < d < m(j).

[0051] In some examples, the cloud service manager 321 may allocate a plurality of resources to each of the plurality of cloud service requests during a plurality of time periods. For instance, a plurality of scenarios may be constructed in which the job may be completed. For each of those scenarios, a plurality of resources may be selected in order to complete the job. However, as described herein, the cloud service manager may also decide not to assign any resources to a particular cloud service request. In such examples, the cloud service manager may determine that a different job with a higher return on resource investment should be executed. Furthermore, the cloud service manager 321 may identify the total resource cost for each possible job. In other words, each job may be associated with a total resource cost. As used herein, a total resource cost refers to the total number of node-periods used to complete a particular job. In a number of examples, the total resource cost and the allocation of resources may be jointly determined to maximize the cloud service provider's revenue received from the plurality of cloud service requests. As used herein, jointly determined may include the resource cost identified first followed by the price being offered. At that moment, both p and x may be derived. In some instance, h may be known when a job is submitted, but it may not be known for future jobs.

[0052] The estimation by the service provider of the total resource cost for a for future service requests (after t^*) may be a probability distribution over different values. To capture the (ex-ante) possibility of different possible costs for a job, different cost types h for each job j may be considered. It may be assumed that the job cost type may be customer's private information. For instance, it may depend on the input data on which a batch application would work. The job cost type may become common knowledge such that both the customer and cloud service provider learn it once the information about The job (and its cost) become available, at time s(j). Therefore, when the cloud provider sets the price menu at time t^*, the provider knows the cost type h(j) of the jobs j arriving at time t^*, but the provider does not know the cost type of future jobs arriving at time t > t^*. In addition to s(j), each job j e J with cost type h has the following characteristics:

r(j,h): the total number of node-periods the job j may require for completion if the job j is of type h.

μ ,ϊι): the probability that job j is of cost type h. Note that∑_h μ(], k) = 1 for each j.

[0053] Based on the input variables, a number of rules (e.g., constraints) may be used by the cloud service provider to generate the cloud service menu. As described further, the rules may include a job completion rule, a one completion per job rule, an elapsed time rule, a maximum number of nodes rule, a node usage rule, an ex-post incentive compatibility rule, an ex-post individual rationality rule, a first and a second job revenue constraint rule, and a minimal node usage rule, among others.

[0054] In an example, for a model formulated with respect to a particular time period t^*, jobs submitted prior to time t^* are known, contracts have been offered and (in some cases) accepted, commitments have been made to honor and accept contracts, and resources have been allocated to begin processing accepted jobs. The relevant information from the prior request for the provider relates to jobs that are in process at time t^*. For these jobs, the provider knows the customer's selection of contract (if any), the time at which a contract was selected, and the resource cost associated with that request. As long as previously signed contracts are honored, the cloud provider can reallocate resources to ongoing jobs.

[0055] Whenever a customer picks a price p(j,d) from the menu and submits a job, the provider already knows the cost type h of the job. On the contrary, multiple values of k may be consistent with the selection of contract p(j,d). The types inferred from the customer's contract selection for job j may be denoted as h(j) and k(j).

[0056] A set of constraints or rules may be maintained that are based on prior decisions that may not be reversed. One constraint or rule may be the fixed work variables for prior time period rule. The rule may be defined by the following:

x(j,h,k,t) = x.fixed(j,h,k,t) for all t < t^*, j for which s(j) < t^*. For time periods prior to the current time t^*, node allocations that were made may not be changed. However, node allocations for periods t > t^* involving jobs that arrived prior to t^*, as long as duration commitments for those jobs are honored. Further, information about cost type revelation h(j) for jobs in the process of being served may be used to improve resource utilization.

[0057] If a contract was accepted for job j, the following is true:

for (h,k) = (h(j),k(j)), x.fixed(j,h,k,t) = x(j,h(j),k(j),t) determined in the solution of the model for t^*-1 .

x.fixed(j,h,k,t) = 0 for all (h,k)≠ (hG),k(j))

If no contract was accepted for job j, then x.fixed(j,h,k,t) = 0 for all h,k,t. [0058] Another constraint or rule may be the fixed completion time commitments for prior requests rule. The rule may be defined as follows:

y(j,h,k,t) = y.fixed(j,h,k,t) for all j for which s(j) < t^*, for all t, u(j,h,k,d) = u.fixed(j,h,k,d) for all j for which s(j) < t^*, for all d. For jobs submitted prior to t^*, the completion time commitments that were made cannot be changed.

[0059] If a contract was accepted for job j, the following is true:

for (h,k) = (h(j),k(j)), y.fixed(j,h,k,t)=0 for all completion times t except the one selected by the customer, which has y.fixed(j,h,k,t)=1

y.fixedG,h,k,t)=0 for all (h,k)≠ (hG),kG))

If no contract was accepted for job j, then y.fixed(j,h,k,t)=0 for all h,k,t.

[0060] If a contract was accepted for job j, the following is also true:

for (h,k) = (h(j),k(j)), u.fixed(j,h,k,d)=0 for all duration d except the one selected by the customer, which has u.fixed(j,h,k,d)=1 u.fixedC,h,k,d)=0 for all (h,k)≠ ( (j),kG)).

If no contract was accepted for job j, then u.fixed(j,h,k,d)=0 for all h,k,d.

[0061] A fixed revenue for prior jobs rule or constraint may be defined as follows:

v(j,h,k,d) = v.fixed(j,h,k,d) for all j for which s(j) < t^*, for all d. For requests submitted prior to t^*, the revenue to be earned from those requests cannot change.

[0062] If a contract was accepted for job j, the following is true:

for (h,k) = (h(j),k(j)), v.fixed(j,h,k,d)=0 for all duration d except the one selected by the customer, which has v.fixed(j,h,k,d)= the revenue v(j,h(j),k(j),d) determined in the solution of the model for t^*-1 .

v.fixedC,h,k,d)=0 for all (h,k)≠ (h(j),kG)).

If no contract was accepted for job j, then v.fixed(j,h,k,d)=0 for all h,k,d.

[0063] A job completion rule or constraint may be defined by the following: ∑tt:s(j)<tt <txG_>h,k,tt)≥ r(j,h)^* y(j,h,k,t) for each j,h,k and t where s(j)≤ t < s(j) + m(j)-1 .

A job j of cost type h for customer type k may not be completed by period t unless at least r(j,h) node-periods have been scheduled between s(j) (the arrival time/earliest start time for job j) and t.

[0064] Another constraint or rule may be the one completion per job rule.

The one completion per job rule may be defined by the following:

^∑t:s(j)≤t≤t+m(j)-i yG'h,k,t) < 1 for each j,h,k. Job j for cost type h and customer type k may be completed in at most one time period t.

[0065] Also, the elapsed time constraint or rule may be defined by the following:

u(j,h,k,t-s(j)+1 ) = y(j,h,k,t) for each j,h,k and t where s(j) < t < s(j) + m(j)-1. If job j is completed at time t for cost type h and customer type k, then its duration (relative to arrival time s(j)) is t-s(j)+1.

[0066] The maximum number of nodes constraint or rule may be defined by the following:

g(j,t)≥ x(j,h,k,t) for each j,h,k and t where s(j) < t < s(j) + m(j)-1 .

The maximum number of nodes assigned to job j in period t over all cost types and customer types may be at least the number assigned to customer type k and cost type h.

[0067] The node usage constraint or rule may be defined by the following:

^∑j:t≥s(j) 9G_>t)≤N for each period t.

[0068] The ex-post incentive compatibility constraint or rule may be defined by the following:

w(j,k,d) - p(j,d) > ε + w(j,k,dd) - p(j,dd) -M^*(1-u(j,h,k,d)) for each j,h,k, d for which 0 < d < m(j) and dd≠d, where ε is a nonnegative number and M is a positive number that may be equal to max j,k,d {w(j,k,d)}.

If job j of cost type h is completed for customer type k in duration d, then u(j,h,k,d)=1 and the last right-hand-side term M^*(1 -u(j,h,k,d)) equals zero. In this case it may be that the customer's surplus (w(j,k,d) - p(j,d)) is at least ε higher than his surplus (w(j,k,dd) - p(j,dd)) under any other duration assignment dd, for dd≠d. [0069] The ex-post individual rationality constraint or rule may be defined by the following:

w(j,k,d) - p(j,d)≥ 0 - M^*(1-u(j,h,k,d)) where M is a very large number, for each j,h,k, and d for which 0 < d < m(j). M needs to be at least as large as max j,k,d {w(j,k,d)}. M may be equal to max j,k,d {w(j,k,d)}.

If job j is completed for customer type k in duration d, then u(j,k,d)=1 and the term M^*(1-u(j,k,d)) equals zero. In such an example, it may be that the customer's surplus w(j,k,d) - pG,d) is nonnegative.

[0070] The job revenue constraintsl rule may be defined by the following: v(j,h,k,d) < p(j,d) for each j,h,k, and d for which 0 < d < m(j).

The revenue earned for job j and customer type k for completion duration d may not exceed the price charged for job j for completion duration d.

[0071 ] The job revenue const.raint.s2 rule may be defined by the following: v(j,h,k,d) < w(j,k,d)^* u(j,h,k,d) for each j,h,k and d for which 0 < d < m(j). The revenue earned for job j of cost type h and customer type k for completion duration d may be zero if the job j of cost type h for customer k is not completed in duration d. Moreover, the revenue earned for job j of cost type h and customer type k for completion duration d may not exceed the customer's willingness to pay for that duration.

[0072] The minimal node-period usage rule may be defined by the following:

∑t_:t≥s(j) xC-h,k,t) < r(j,h) for each j, h, k.

[0073] Further, variable domain rules define the domains for each of the variables described herein, and may be as follows:

xC,h,k,t): e{0, 1 ,2, ...,N}

yC,h,k,t): e{0, 1}

g(j,t) continuous between 0 and N

u(j,h,k,d) continuous between 0 and 1

v(j,h,k,d) continuous, nonnegative

p(j,d) continuous, nonnegative

[0074] The interaction between each customer and the cloud resource provider in any period t^* may include the following. At time t^*, a number of jobs j are submitted for execution. For instance, these are requests for which s(j) = t^*. Once a job is submitted, the cloud provider discovers its type h and its cost condition (e.g., requirement) r(j,h). Given this information and the available resources at time t^*, the cloud provider sets the menu of prices {p(j,d)}.

[0075] Given the menu {p(j,d)} and a customer's willingness to pay w(j,k,d), a customer who submitted jobs j with arrival time t^* decide whether to select an item from the menu and sign a contract with the cloud provider. For instance, if the customer chooses and pays p(j,d), the provider commits to completing the job within d periods, and revenue v(j,k,h,d) is realized. At this stage, the values x(j,h,k,d) for all j that are in process in t^* are determined. If the customer submitting a job j chooses nothing, no revenue is realized and xG,h,k,d)=0 for all h,k,d.

[0076] The objective is to maximize the expected revenue from all current and future jobs and derive endogenous variables therefrom. Therefore, the objective function may be defined by the following:

Maximize z

k) * v(j, k, h(j), d) +∑j,k,h,d_:s(i)>t*"(j, k) * μ(], η) * v(j, k, n, d).

The first term of the objective function relates to those jobs submitted at time t^*. For jobs j submitted at time t^* and given the interaction described above, the cloud provider may know the cost type h(j) and does not know the customer type k. The probability distribution TT(j,k) takes care of the uncertainty of the cloud provider with respect to the customer's willingness-to-pay. The second term of the objective function relates to jobs arriving after t^*. For such jobs, the provider faces uncertainty in the cost type h and in the customer type k. The probability distribution

appears in the second term, taking care of the uncertainty of the cloud provider over the cost type of jobs arriving after t^*. The uncertainty over the sequencing (and nature) of the jobs over time is reflected by the option for the provider of re-optimizing at each period in light of the best information available at the moment. Therefore, if new information arises or old information needs to be updated, the cloud provider can re-run the optimization program described above subject to the aforementioned constraints. [0077] Using the variables determined, the rules provided above, and the mixed integer program solver 322, the above objective function may be determined. In other words, an allocation of resources may be determined in order to complete all cloud service requests received from users 324, while maximizing profit for the cloud service provider.

[0078] Examples are not limited to the constraints listed above, and additional and/or different constraints may be employed. These extra constraints or rules may allow the cloud provider to take into account specific characteristics of the cloud system, special requests from the customers, or other factors. For example, one example may include an additional constraint on the maximum number of nodes a(j) that a job can use in a given period: x(j,h,k,t) < a(j) for each j,h,k and t for which s(j) < t < s(j) + m(j)-1 .

[0079] Furthermore, some job applications may require some nodes to be reserved to the job in each period for the whole processing time. In such examples, two types of nodes may be distinguished: "active" nodes whose assignment over time to the job affect the job-completion time, and "passive" nodes that are assigned to the job in order to keep it running, but do not impact the completion time. In such examples, the resource condition r(j,h) may only be in terms of "active" nodes. Some of the reserved nodes maybe passive. The total number of reserved nodes associated to job j may be set as b(j), and the number of passive preserved nodes associated to the job j may be set as a(j) (i.e. aC)≤bO ).

[0080] In examples where "active" nodes and "passive" nodes are assigned, the following variables and constraints may be employed. First, an additional variable may be included: i(j,h,k,t), which is a binary variable indicating whether a positive number of nodes is assigned to job j of cost type h at time t for customer type k. This variable may be defined for t such that s(j) < t < s(j) + m(j)-1 . Second, three additional constraints or rules may be included. The three additional constraints or rules may be defined as follows. A work indicator constraint or rule may be defined as:

x(j,h,k,t) < N^*i(j,h,k,t) for each j,h,k, and t where s(j) < t < s(j) + m(j)-1 . This constraint forces the indicator variable i to be positive if x is positive, and forces x to be zero if i is zero.

[0081 ] Also, a minimum number of nodes constraint may be defined as: x(j,h,k,t)≥ b(j)^*i(j,h,k,t) for each j,h,k, and t where s(j) < t < s(j) + m(j)-1 . This constraint forces at least b nodes to be used in any period where nodes are used for a job.

[0082] Additionally, a contiguous work constraint may be defined as: i(j,h,k,t)≥ i(j,h,k,tt) + i(j,h,k,ttt) -1 for each j,h,k, and t where s(j) +1 < t < s(j) + m(j)-2, and tt<t and ttt>t.

If work is done for a job j and types k and h in earlier period tt and later period ttt, then work may also be done in period t.

[0083] Also, in some examples, the Job completion2 constraint may be replaced with the following:

∑tt:s₍j) < tt < t( xG,h,k,tt) - a(j) iG,h,k,t) )≥ r(j,h)^* y(j,h,k,t)

and the minimal node usage constraint may be replaced with the following:

∑t:t> _S(j) ( ^xC-h,k,t) - a(j) iC-h,k,t) ) < r(j,h) for each j, h, k.

[0084] As noted, examples of the present disclosure may be applied within an enterprise to distribute cloud resources (i.e. the nodes) across different departments or business units. In this case, prices p(j,d) are transfer prices that are charged to the departments that rent the nodes. Instead of maximizing profits, it may be more appropriate to select the prices in order to implement the allocation of nodes that maximizes efficiency, or, in other words, the summation of the business unit's utilities. In each period t^*, the enterprise cloud resources manager maximizes the following:

Maximize zz =∑_j,k,d:s(j)=t^(j, k) * u(j, k, h(j), d) * w(j, k, d) +

¾ΐ!,ά )>ι^*π(]' k) * μθ. ^h) * ^UG< ^k< ^h< ^d) * ^w0< ^k< ^d)-^■

This objective function represents customers' total willingness to pay for the job completions achieved by the enterprise cloud resources manager.

[0085] An environment with an alternate interaction may be considered. For instance, the provider may not know the cost type h and associated job cost r(j,h) before the price menu to offer for jobs j arriving in t^* is determined.

Moreover, the provider may need to commit to a menu and to honoring the customer's selection before knowing the cost type h for jobs arriving in t^*. In that case, the provider may determine the job completion time independently of h or the resource condition r(j,h). Such an environment may be referred to as "blind" because the provider may make a commitment to a completion time without knowing the true conditions. To model this environment, changes are made to the aforementioned approaches. For example, the following variables may be considered for this blind commitment interaction:

x(j,t): integer maximum number of nodes assigned to job j at time t over all cost types h and customer types k. This is defined for t such that s(j) < t < s(j) + m(j)-1.

y(j,k,t): binary variable indicating if job j completes at time t for customer type k. This is defined for t such that s(j) + l(j) -1 < t < sC) + mC)-1.

u(j,k,d): (binary) variable indicating if job j completes with elapsed time d from earliest start time for customer type k. An integrality constraint for this variable may be relaxed. This is defined for d such that l(j) < d < m(j).

v(j,k,d): revenue earned for job j d periods after its arrival for customer type k. This may be forced to coincide with p(j,d)^* u(j,k,d) by the constraints. This is defined for d such that l(j) < d < mC).

p(j,d): price offered for completion of job j d periods after its arrival.

This is defined for d such that l(j)≤ d < m(j).

The g variables have been dropped in this formulation associated with the blind commitment interaction.

[0086] Constraints with respect to the blind commitment interaction may include dropping the dependence on h from the y, v, and u variables and dropping the dependence on k,h from the x variables. Furthermore, the

"maximum number of nodes" constraint may be dropped. Changes to node usage constraints may include a function:

∑j:t≥s(j) xG,t)≤ N for each period t. [0087] Such a function is used because a cloud service provider cannot use more than the available number of nodes (N) in each period. In the example, g has been replaced with x in the node usage constraint.

[0088] With respect to minimal node usage, more node-periods for job j cannot be used than may be required, leaving the function:

∑t:t≥s(j) xG,t)≤ maxh{r(j,h)} for each j.

[0089] With respect to the blind commitment interaction, a third objective function may be considered, differing from the first in that only a single term is applying for all jobs (those arriving in t^* and later) and uncertainty over h applies to all of them:

Maximize z = ^j,_k,_h,d:s(J)≥t*^' ^h^> * ' ^k * ^νϋ· ^k> ^h> ^d)- [0090] With respect to non-reversible parameters, the following may be maintained with respect to the third objective function:

x.fixed(j,t) for all t<t^*, j for which s(j)<t^*

If a contract was accepted for request j, then the provider is informed of the cost type h for request j, and the associated resource cost r(j,h). The provider can then use this information to determine the resource assignments for job j in each period.

x.fixed(j,t)= x(j,t) determined in the solution of the model for t^*-1. If ∑t:s(j)≤t<t* x(j,t) > r(j,h), then the provider can reduce x.fixed(j,t) for the largest t<t^* until ∑t: s(j)≤t<t* x.fixed(j,t) = r(j,h).

If no contract was accepted for request j, then x.fixed(j,t)=0 for all t.

[0091] With respect to the third objective function, the fixed work variables for prior time period rule may be adjusted such that the rule may be defined by the following:

x(j,t) = x.fixed(j,t) for all t < t^*, j for which s(j) < t^*.

[0092] Figure 4 illustrates an example menu 430 for pricing of cloud resources according to the present disclosure. Menu 430 includes a particular example for a particular job j. A different job would have a different menu. Menu 430 illustrates a duration of service time and a price for the job. In this example, the longer the duration of serve, the less expensive the job. [0093] Figure 5 illustrates an example flow chart of a method 540 for price, completion time, and resource allocation determination for cloud services according to the present disclosure. At 542, the method 540 can include continuously receiving, by a cloud service manager, a plurality of cloud service requests from a plurality of users in a cloud system. As discussed in relation to Figure 3, users 324 may submit cloud service requests online to the cloud service manager 321. In some examples, the method 540 can include receiving a list of cloud service requests that the cloud service provider needs to consider. For example, each of the plurality of cloud service requests may be indexed, the indexing which may assist in the assignment of resources to complete each service request by particular completion times.

[0094] At 544, the method 540 can include determining by the cloud service manager, a plurality of completion times for a subset of the plurality of cloud service requests based on availability of resources in the cloud system, beliefs about future service requests, and information previously gathered with respect to the plurality of users and the plurality of cloud service requests, wherein each completion time is associated with a resource allocation and a price. In some examples, a plurality of cloud service requests may be received, but the cloud service manager may only determine completion times for some (e.g., a subset) of the cloud service requests received. For example, the user may request a particular cloud service, such as a Monte Carlo simulation. A plurality of different completion times may be determined for the Monte Carlo simulation. For instance, the cloud service provider may determine that the simulation could be completed by 12:00am central time, December 1 1 , 2015, 12:00am central time, December 10, 2015, or 1 :00pm central time, December 5, 2015. Based on the type and amount of cloud service requests received by the cloud service manager, various options for completion time may be provided for each requested cloud service.

[0095] The method 540 can include determining by the cloud service manager, a price for each of the plurality of service requests based on the determined completion time. For example, using the variables and rules described in relation to Figure 3, the cloud service manager may determine a price for each of the cloud service requests. Similarly, the cloud service manager may determine a price for the completion time and resource allocation for each of the cloud service requests. For instance, the price pG,d) for the completion of job j after d periods from the job arrival time/earliest start time s(j) may be determined. Price consideration may also be based on information gathered from previous offers, for instance, new information associated with jobs and/or customers.

[0096] At 546, the method 540 can include offering, by the cloud service manager, to a user among the plurality of users, a menu of the plurality of completion times for a cloud service request among the plurality of cloud service requests, wherein each completion time is offered with the associated price. Further, at 548, the method 540 can include allocating, by the cloud service manager, resources in the cloud-based system to fulfill a selected service request by a user among the plurality of users of the cloud system. For example, if a user among the plurality of users of the cloud system purchased a particular pricing option for a requested cloud service, resources in the cloud system may be allocated to specifically perform that requested cloud service within the agreed upon completion time.

[0097] The method 540 may further include providing a menu of service price options to the customer based on availability of resources, customer willingness to pay for each service, the cloud service requests received, beliefs on future service requests, and the information previously gathered. For example, once all price options are determined for each of the cloud service requests received, the cloud service manager may present a menu of pricing options to each of the users, as discussed in relation to Figure 3.

[0098] Method 540 may also be applied to distribute private cloud resources across different departments within an enterprise. In such a case, output-based QoS level-defined price (e.g., price per job duration) becomes the transfer price that a department is charged for using the enterprise resources necessary to implement the related output-based QoS level. Allocating resources may be done to maximize efficiency in such an example. To derive prices and regulate the resource distribution within the enterprise, an objective may be to maximize the aggregate willingness to pay w(j,k,d) of all departments submitting requests.

[0099] Method 540 may be performed iteratively. For instance, a plurality of requests may be received by a cloud service manager continuously. As these requests are received, completion times and/or prices to offer may be determined by the provider dynamically. These offers take into consideration information gathered previously, as the method 540 is performed iteratively. This information is continuously and/or dynamically updated, as the method 540 continues to be performed.

[00100] Examples of the present disclosure may allow for a practical implementation of the sale of performance-based cloud services by focusing on a performance dimension given by completion times. This mechanism may allow for market expansion and price discrimination. Selling completion-times may allow for charging higher prices to customers with higher urgencies to complete their jobs. Under certain conditions, this may imply higher profits for the cloud service provider. Similarly, when applied within an enterprise, the examples of the present disclosure implement methods to distribute resources across departments. Priorities may be established in terms of users' relative urgency of getting jobs done by a certain time. The amount of resources assigned to a department may depend on what is needed to get the job done by a certain time. As such, it may fluctuate over time (depending on the other jobs submitted).

[00101] Finally, because resources are released at job completion, under certain conditions, such job-centric criterion for resource distribution may bring higher efficiency. As compared to other pricing and allocation approaches, examples of the present disclosure, as noted above, tackle three kinds of uncertainties: uncertainty about the sequence of requests that will arrive over time; uncertainty about the willingness to pay of different customers; and uncertainty about the resource demand of each job/service requested by a customer. The online nature allows the cloud service provider to re-optimize constantly, as new information about jobs and customers arise. [00102] In the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how a number of examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be used and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

[00103] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure.

[00104] In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense. As used herein, the designators "N", and "P", particularly with respect to reference numerals in the drawings, indicate that a number of the particular feature and/or component so designated can be included with a number of examples of the present disclosure. The designators "N" and "P" can refer to a same feature and/or component, or different features and/or components.

[00105] As used herein, "logic" is an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. Further, as used herein, "a" or "a number of something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. Also, as used herein, "a plurality of" something can refer to more than one of such things.

[00106] The above specification, examples and data provide a description of the method and applications, and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the system and method of the present disclosure, this specification merely sets forth some of the many possible embodiment configurations and implementations.

Claims

What is claimed:

1. A system, comprising:

a request engine to continuously receive requests for cloud services from a plurality of users of a cloud system;

an input engine to receive a plurality of parameters relating to the requested cloud services from at least one of each of the plurality of users and a provider of the cloud system;

an output engine to determine a plurality of variables relating to each of the requested cloud services using the plurality of parameters and a mixed integer programming solver, wherein a variable among the plurality of variables includes a number of resources to be allocated; and

a menu engine to generate a cloud service menu in response to each of the continuously received requests to be offered to the plurality of users, the cloud service menu defining prices, and associated completion times for each of the requested cloud services.

2. The system of claim 1 , further comprising an optimization engine to dynamically optimize the prices and the associated completion times as new requests for cloud services are received.

3. The system of claim 1 , further comprising the output engine to identify a plurality of resources to complete a subset of the cloud service requests received.

4. The system of claim 1 , further comprising a selection engine to record a particular menu item selection in the cloud service menu by a user from the plurality of users.

5. The system of claim 4, further comprising the selection engine to execute jobs according to the selected menu item.

6. A non-transitory machine-readable medium storing instructions executable by a processing resource to cause a computing system to:

continuously receive from a plurality of users of a cloud system, a plurality of cloud service requests;

determine resources in the cloud system to be allocated to a subset of the requested cloud service requests based on the plurality;

provide a pricing option to a subset of the plurality of users for completion of a subset of the plurality of cloud service requests using a resource cost, a completion time, beliefs on future service requests, and information gathered from previously provided pricing options; and

allocate resources in the cloud system to fulfill a user selected pricing option.

7. The medium of claim 6, including instructions executable to receive a total number of node periods required to complete each of the plurality of cloud service requests.

8. The medium of claim 6, including instructions executable to receive a probability that a cloud service request among the plurality of cloud service requests is of a particular job type.

9. The medium of claim 6, including instructions executable to identify a total number of node periods to complete the cloud service request based on the determined job type.

10. The medium of claim 6, including instructions executable to receive a probability that a cloud service request among the plurality of cloud service requests is received from a particular user type.

1 1 . The medium of claim 6, including instruction executable to jointly determine the pricing options and allocate the resources in the cloud system to maximize revenue received from the plurality of cloud service requests.

12. A method, comprising:

continuously receiving, by a cloud service manager, a plurality of cloud service requests from a plurality of users in a cloud system;

determining by the cloud service manager, a plurality of completion times for a subset of the plurality of cloud service requests based on availability of resources in the cloud system, beliefs on future service requests, and information previously gathered with respect to the plurality of users and the plurality of cloud service requests, wherein each completion time is associated with a resource allocation and a price;

offering, by the cloud service manager, to a user among the plurality of users, a menu of the plurality of completion times for a cloud service request among the plurality of cloud service requests, wherein each completion time is offered with the associated price; and

allocating, by the cloud service manager, resources in the cloud-based system to fulfill a selected service request by a user among the plurality of users of the cloud system.

13. The method of claim 12, wherein:

the cloud system is a private cloud system;

a price per job duration is a transfer price; and

allocating resources comprises allocating resources to maximize efficiency.

14. The method of claim 12, wherein the method is performed iteratively.

15. The method of claim 12, including providing a menu of service price options to a user among the plurality of users based on availability of resources, customer willingness to pay for a cloud service completion time, the cloud service requests received, beliefs on future service requests, and the information previously gathered.