WO2016186631A1

WO2016186631A1 - Price, completion time, and resource allocation determination for cloud services

Info

Publication number: WO2016186631A1
Application number: PCT/US2015/031244
Authority: WO
Inventors: Filippo Balestrieri; Julie Ward Drew
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-05-15
Filing date: 2015-05-15
Publication date: 2016-11-24

Abstract

Techniques are provided for price, completion time, and resource allocation determination for cloud services. A system for price, completion time, and resource allocation determination for cloud services can include a request engine to receive a request for a cloud service from a user of a cloud system, an input engine to receive a plurality of parameters relating to the requested cloud service from at least one of the user and a provider of the cloud system, an output engine to determine a plurality of variables relating to the requested cloud service using the plurality of parameters and a mixed integer programming solver, and a menu engine to 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.

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 flow chart of a method for price, completion time, and resource allocation determination for cloud services according to the present disclosure. Detailed Description

[0006] The cloud computing model allows users (e.g., customers) to rent computing infrastructure as needed, rather than requiring them 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 requirements 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.

[0007] 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. An example of a cloud service may be a Monte Carlo simulation.

Another example of a cloud service may be an optimization problem. Another example is a data mining job. Put another way, 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.

[0008] In the instance-based model, a cloud provider may rent out nodes, servers and/or VMs. However, such models are resource based and require the customer to define the number and type of cloud resources that are needed to perform a given service, as well as how long they are needed for. Knowing exactly how many, which kind, and how long cloud resources are needed may require a level of technical expertise that the customer doesn't 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 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.

[0009] 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.

[0010] Moreover, a cloud service provider may have limited resources. The service provider may face a set of potential customers requesting different services. Each service may be described in terms of starting 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). The service provider may choose how to assign resources to the service over time in order to satisfy the total resource cost requirement. 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...). [0011] Still further, price and completion time determination in the cloud context may be subject to two or more sources of uncertainty: the customers' willingness to pay for various cloud services; and uncertainty over the total resource cost 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.

[0012] 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. Examples of the present disclosure may include systems, methods, and machine-readable and executable instructions and/or logic.

[0013] 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, the objective function (described further herein) may be to increase benefits of the cloud services derived by the users within the company and/or organization.

[0014] 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.).

[0015] 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 a cloud service request offline from a user 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).

[0016] The request engine 103 may include a combination of hardware and programming that is configured to receive a cloud service request offline from a user (e.g., customer) of a cloud system. As used herein, a cloud service request received offline refers to a cloud service request that is submitted during a first window or time period during which users may submit cloud service requests, and which can be executed during a second window or time period. For example, a first window or time period (e.g., the "offline" window or time period) may be a period of time during which users may submit cloud service requests. Similarly, a second window or time period, such as an "execution" window or time period, may be a period of time during which the requested cloud services are executed. In the foregoing examples, "time" is considered a sequence of discrete intervals (e.g. minutes, hours, days, ...) during the second window, i.e., the execution time period. Given that, a set of time periods T = {1 ,...,T} may be considered. At the beginning of the first period, the full list of cloud service requests (e.g., jobs) that the provider needs to consider may be known. The last period T may define the horizon length over which the price and resource allocation system 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.

[0017] In some examples, the system 100 may include a compilation engine (not illustrated in Figure 1 ). The compilation engine may include a combination of hardware and programming that is configured to compile a list of cloud service requests received from a plurality of users of the cloud system. For example, a plurality of cloud service requests may be received from a plurality of users. The compilation engine and/or a cloud service manager (discussed further in relation to Figure 3) may determine a full list of the cloud service requests received. For example, a first user of the cloud system may request a Monte Carlo simulation, and a second user of the cloud system request an optimization problem. The compilation engine may determine that a request for a Monte Carlo simulation and a request for an optimization problem have been received.

[0018] The input engine 104 may include a combination of hardware and programming that is configured to receive parameters relating to the requested cloud service from at least one of the user 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.

[0019] 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, the parameter represented by s(j). The value of s(j) may correspond to the job j's arrival time or to the time the job j may begin. Another example of a parameter may be the total number of node-periods that the job j may require 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 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: μ (j,h) , the probability that job j is of type h, and n(J, k), the probability that job fs customer is of type k.

[0020] The output engine 105 may include a combination of hardware and programming that is configured to determine a plurality of variables relating to the requested cloud service using the plurality of parameters and a mixed integer programming solver. 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 between 0 and 5 (e.g., 0, 1 , 2.5, 4.1 , etc.).

[0021] 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, 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.

[0022] The menu engine 106 may include a combination of hardware and programming that is configured to 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. 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). 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.

[0023] 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 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.).

[0029] 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.

[0030] The request module 213 may include instructions that when executed by the processing resource 209, may receive from a plurality of users of a cloud system, a plurality of cloud service requests. As described in relation to Figure 1 , a single cloud service request may be received from a single user of the cloud system, or a plurality of cloud service requests may be received (e.g., from a single user and/or from a plurality of users of the cloud system).

[0031] 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. 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 service 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.

[0032] 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.

[0033] 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. 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.

[0034] In some examples, the computing device 208 may further include instructions that when executed by the processing resource 209 may determine a job type for each cloud service request received from users of the cloud system, and determine a total number of node periods to complete each of the cloud service requests based on the determined job type and size. For example, a Monte Carlo simulation may require 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 determine 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., and using a plurality of constraints and/or rules, 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.

[0035] 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). 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 may be non- perishable in that they do not expire after a certain time.

[0036] The cloud service manager 321 may deploy and manage cloud services. For instance, the cloud service manager 321 may receive requests offline for cloud services from a plurality of users 324-1 , ...324-P (e.g., customers) of a cloud system. Put another way, at time 0 all requests for cloud services j may be collected. Each service request may also be referred to as a "job". Before time period 1 , the full set of jobs may be known. Each job may be indexed by j. Further, the set of jobs may be represented by J = {1 , ...,J}. Each job served may have a number of resources (e.g., nodes) assigned 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.

[0037] As discussed previously herein, each job j e j may have the following characteristics:

s(j) : the earliest period in which the job j can start. This might correspond to the job's arrival time or to the time the job j may begin.

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.

[0038] Each service request (e.g., job) may be interpreted as a separate customer with a given willingness to pay for the particular job. The set of customer types may be defined by K = {1 ,...,K}. Further, the service provider's belief of the customers' willingness to pay for the service may be represented by a probability distribution over different types of customers. For instance, different job and customer type combinations {j,k) may have the following characteristics:

n j, k): the probability that job j's customer is of type k. Note that ∑_fe k) = 1 for each j.

w(j,k,d): A customer of type ks willingness to pay for job j if it is completed during d periods after arrival time s(j).

[0039] As discussed previously herein, the total number of nodes or resources needed to complete a particular job may be determined. The total number of available nodes and/or resources for the cloud service provider may be represented by N.

[0040] 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{c/: w(j,k,d)>0}}. In some examples, the horizon length may be represented by T =

{s(j) + m(j)} to ensure enough time in the horizon to complete every job received from the users 324. 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.

[0041] 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, the cloud service manager 321 may determine a plurality of resources 323 for each cloud service request received.

[0042] 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) + 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

s(j)≤t≤s(j) + m(j) - -\ .

u(j,h,k,d): binary variable indicating if job j of cost type h completes with elapsed time d from earliest start time 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. This may coincide with p(j,d)^* 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 the job's arrival. This may be defined for d such 0 < d≤ m(j). Notably, the number of integer variables may equal 3JHK maxj{m(j}}, assuming that the u variables are continuous between 0 and 1. However, not every customer type may be relevant for every job, in which case the number of variables may be much smaller.

[0043] 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 determine 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 required 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.

[0044] The estimation by the service provider of the total resource cost for a job may be a probability distribution over different values. To capture the possibility of different possible costs for a job, different cost types h for each job j may be considered.

[0045] 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 incentive compatibility rule, an individual rationality rule, a first and a second job revenue constraint rule, and a minimal node usage rule, among others.

[0046] One constraint or rule may be the job completion rule. The job completion rule may be defined by the following: _tt.sQ_)≤tt≤tx0.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 earliest start time for job j) and t.

[0047] 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:sO)≤t≤i+mO)-i yG'h,k,t) < 1 for each j,h,k. Job / for cost type h and customer type k may be completed in at most one time period t.

[0048] 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 ί-ε +Ί .

[0049] 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.

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

^∑ _j:t>sO) 9(j>t)≤/V for each period t.

[0051 ] The 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 required 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. [0052] The 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 required that the customer's surplus w(j,k,d) - p(j,d) is nonnegative.

[0053] 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.

[0054] 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.

[0055] The minimal node usage rule may be defined by the following:

∑t:t>sO) x(j,h,k,t)≤ r(j,h) for each y, h, k.

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

x(j,h,k,t): e{0, 1,2, ...,N}

y(j,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

[0057] The objective function is to maximize the expected revenue from all jobs. Therefore, the objective function may be defined by the following:

Maximize z =∑],k,h,d^ j> h) * k) * v j, k, h, d) 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.

[0058] 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.

[0059] 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 required to be assigned to the job in order to keep it running, but do not impact the completion time. In such examples, the resource requirement 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. a(j)≤ b(j) ).

[0060] 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 / to be positive if x is positive, and forces x to be zero if / is zero.

[0061] 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.

[0062] Additionally, a contiguous work constraint may be defined as: i(j, ,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 must also be done in period t.

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

Z_tt:su_)≤tt≤t( xO,h,k,tt) - a(j) i(i,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}O₎ ( x(i_>h,k,t) - a(j) i(j,h,k,t) )≤ r(j,h) for each y, h, k.

[0064] Figure 4 illustrates an example flow chart of a method 430 for price, completion time, and resource allocation determination for cloud services according to the present disclosure. At 431 , the method 430 can include 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 offline to the cloud service manager 321. In some examples, the method 430 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.

[0065] At 432, the method 430 can include determining a plurality of completion times for a subset of the plurality of cloud service requests based on availability of resources in the cloud system, 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.

[0066] The method 430 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 p(j,d) for the completion of job j after d periods from the job starting time s(j) may be determined.

[0067] At 433, the method 430 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 434, the method 430 can include allocating, by the cloud service manager, resources in the cloud system to fulfill a selected service request by a client 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.

[0068] The method 430 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, and the cloud service requests received. 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.

[0069] 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.

[0070] 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. 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.

[0071] 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. [0072] 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 receive a request for a cloud service from a user of a cloud system;

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

an output engine to determine a plurality of variables relating to the requested cloud service 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 to be offered to the user, the cloud service menu defining a price and a completion time for the requested cloud service.

2. The system of claim 1 , wherein the requested cloud service is a batch application.

3. The system of claim 1 , further comprising a compilation engine to compile a list of cloud service requests received from a plurality of users of the cloud system.

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

5. The system of claim 1 , further comprising a selection engine to record a user's selection of a particular menu item in the cloud service menu.

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

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

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;

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 and completion time; and

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

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

9. The medium of claim 7, including instructions to determine a probability that a cloud service request among the plurality of cloud service requests is of a particular job type.

10. The medium of claim 7, including instruction to determine a total number of node periods to complete the cloud service request based on the determined job type.

1 1 . The medium of claim 7, including instructions to determine a probability that a cloud service request among the plurality of cloud service requests is received from a particular user type.

12. The medium of claim 7, including instructions 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.

13. A method, comprising:

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, 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.

14. The method of claim 13, including receiving a list of cloud service requests for the cloud service provider to consider.

15. The method of claim 13, 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, and the cloud service requests received.