Keywords

1 Introduction

1.1 Background

The development of computing has been driven by the constant increase in computational demand [1]. During this development, computing has evolved through cluster computing, grid computing, and cloud computing [2], with cloud computing being the most popular paradigm.

Basically, cloud computing is a form of computing, in which resources are outsourced through the Internet to data centers that pool large computing resources [3]. The capability of resource pooling and service metering enables cloud computing to offer services on demand and as pay-per-use [4, 29], allowing users to fulfill their computing needs rapidly, minimal technical skills, and no upfront cost. Cloud services can be provisioned as one of three service models (infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS)) and one of three deployment models (private cloud, community cloud, and public cloud) [4, 7]. The ability to offer on-demand computing services has created a big demand for cloud computing and, hence, a significant market growth in the cloud computing field.

However, the demand for cloud computing services is not steady and changes with the change in customer needs. The fluctuating computational demand for cloud services brings in significant challenges to the CSPs. For example, if CSPs make sure to fulfill any extreme demand by over provisioning of resources, it leads to resource underutilization for most of the time and, hence, the approach becomes economically inefficient.

One of the effective approaches to deal with fluctuating computational demand is to outsource the computing jobs beyond any CSPs resource limitation to other CSPs that have their resources underutilized. Cloud federation is a platform that is named for such an approach [26]. CSPs, by being the member of the cloud federation [36], cooperate with each other by providing resources to fulfill user demand and increase their profits [30, 31, 33].

Besides, according to a recent study, more than 68% of the global cloud market is being captured by six big providers [6]. In such an oligopolistic market, network externalities and economies of scale can provide potential limitation for small CSPs to compete with these big players [7, 36]. Cloud federation can provide a way for small CSPs to increase their competitive strength and increase their market share [36].

1.2 Study Objectives and Contributions

Cloud federation is an appropriate way to address the need of cloud elasticity by expanding resources beyond the limited capacity of a single CSP. It is also a way to get profit out of, otherwise, unused resources for any CSP. However, an alliance can be formed, only if potential members (CSPs) see marginal benefits in joining the federation. For this, a proper economic model is necessary for achieving a fair distribution of revenue. The revenue distribution can depend on the contributions made by each member CSPs in the federation. Such a fair revenue sharing model is also essential for sustaining an alliance.

With the realization for the need of cloud federation, studies on economic models applicable for cloud federations emerged. In particular, previous works focus on revenue sharing models that maximize total social benefits of federations [8, 9]. Other works attempt maximizing the profit of an individual CSP in an federation that operates in a non-cooperative environment [10, 11]. So far, however, no work provides a revenue sharing model for cloud federation within a cooperative environment that is proportionate to the contributions of each member of the federation, which is addressed in this article. Therefore, our objective is to determine whether the Shapley value method could be applied to cloud federations.

For the analysis, we developed a Java program for simulating an environment with five CSPs making available a certain number of virtual machines (VMs). Each simulation run included 100 job requests demanding a random number of VM instances. The simulation runs were carried out for four different scenarios, to capture the effectiveness of the model with respect to the size of job requests and resources made available by CSPs to the federation.

The contributions of this paper are twofold: First, we state that the Shapley value method is an appropriate method for sharing revenue among the members of a cloud federation. The Shapley value method calculates the revenue share for each member CSP according to their marginal contributions to the federation [12, 24]. Second, we verify through simulation that: (i) the total revenue is maximized for large job requests, if the CSPs work in a federation; (ii) the Shapley value method provides a fair way of dividing the revenue; and (iii) the Shapley value method achieves a higher revenue than the basic method that calculates revenue share on the basis a CSP’s resources made available as a fraction of total available resources of the federation.

The remainder of the paper is organized as follows: Sect. 2 describes related works. The system model is presented in Sect. 3. Section 3.2 discusses the proposed approach of revenue sharing based on Shapley values in cloud federations. Details on the simulation experiments and result analyses are presented in Sect. 4. Finally, the paper concludes with a discussion and conclusion in Sect. 5.

2 Related Works

Several works have addressed cloud federations. A vision, challenges, and architectural elements of federated cloud computing environments are presented by Buyya et al. and Jeffery et al. [13, 38]. These works support application scaling across multiple CSPs and consider policy impact as also outline by Hofäcker et al. [37]. Frameworks for cloud federations that employs the role of broker have also been proposed [14, 35]. Multi-agent protocol is proposed by Messina et al. and is applicable for negotiations of service level agreements in cloud federations [17]. Suzic et al. propose an architecture for security governance that aims to provide a transparent and secure sharing of infrastructure and data within the heterogeneous environment of cloud federation [22].

Economic benefits of cloud federation are also discussed [16, 28, 32]. With a survey of conceptual background about federation of small CSPs, Kim et al. provide a guidance for defining economic problems of cloud federation [7]. Drivers and barriers have been discussed as well [36]. A cost model for federated hybrid clouds is presented by Kashef and Altmann [15, 26].

An economic model for the federation of cloud service providers is presented by Goiri, Guitart, and Torres as well as Kashef and Altmann [19, 26]. The proposed model helps CSPs to make decisions with regards to outsourcing, in-sourcing and turning off unused nodes based on different environmental factors. As a solution to the problem of limited resources, Bouabdallah et al. propose a distributed approach relying on contract net protocol [20]. It considers various parameters relating to a service provider, client and quality of service for virtual machine placement. Interoperability and openness aspects have also been discussed [27, 28]. Hadji et al. propose an algorithm for allocation of critical resources in a cloud federation (i.e., for selecting hosting resources and placing applications and services) that aims at optimizing cost efficiency [18]. Li et al. studied on auction methods (non-cooperative method) as a way of maximizing profits in cloud federation where buying and selling of the resources between customer and provider of cloud services [10, 34]. In their work [8], Hassan et al. present a mechanism to share resources and revenue among cooperative members in an alliance of CSPs that aim at maximizing social welfare.

In their work [21], Barril et al. analyze the organizational as well as technology integration challenges and identify incentives that make CSPs willing to aggregate the resources and form a federation. It is argued that the Internet of Things (IoT) will be the main business driver and motivation for cloud federation. Another mechanism for the formation of cloud federation is proposed by Mashayekhy et al. The mechanism aims at maximizing the profit of the federation [5].

A game-theoretic policy-based decision-making process is presented by Lu et al., which helps cloud providers to form an alliance that helps improving resource utilization and maximizing profit [9]. Samaan presents an economic model for sharing resources by modeling the interactions of CSPs as a repeated game among selfish players [11], where the CSPs maximize their profit by selling their unused resources to the spot market.

3 System Model

3.1 Stakeholders and Parameter Definitions

For developing the system model of a cloud federation, we consider the broker-based architecture as proposed by the National Institute of Science and Technology [23] and further researchers [27, 31, 40]. It considers five types of stakeholders (Fig. 1).

Fig. 1.
figure 1

Interaction between stakeholders in a cloud federation.

The cloud brokers maintain information about cloud providers, such as the cost for each type of VM instance. In detail, for each cloud provider (CSP) in the federation, the availability and the cost of resources is periodically updated by cloud brokers. The cloud consumers specify the resource requirements for various time slots. They place service requests to brokers for such resource requirements. Cloud providers maintain resources and update their price list. These cloud providers provide resources to cloud service users in the form of virtual machines. They communicate with the cloud brokers about their offers for cloud resources. The cloud auditors make sure that the transactions between consumers, providers, and brokers follow regulations. The cloud carriers provide the communication service for the other stakeholders. Formally, the stakeholders are represented as follows in the system model. Cloud providers Pi are represented as a set of size n, as shown in Eq. 1.

$$ {\text{P}} = \left\{ {{\text{P}}_{1,} \ldots ,{\text{P}}_{\text{n}} } \right\} $$
(1)

Each virtual machine is defined by a certain capacity of the processing core, memory, and storage. For our system model, we limit the types of virtual machines to m. Therefore, VMs can only be provisioned as one of m VM types (Eq. 2).

$$ {\text{V}} = \left\{ {{\text{V}}_{1} , \ldots ,{\text{V}}_{\text{m}} } \right\} $$
(2)

Cloud consumers send requests R for a number of instances of different VM types. It is defined as a set of requested numbers of VM instances Rj of type Vj (Eq. 3).

$$ {\text{R}} = \left\{ {{\text{R}}_{1} , \ldots ,{\text{R}}_{\text{m}} } \right\} $$
(3)

Although there are different costs for running different VM types of different CSPs, the broker sets a fixed retail price for each of the VM types. The retail prices are represented as a set S (Eq. 4), where Sj refers to the retail price of one instance of VM type Vj per unit of time.

$$ {\text{S}} = \left\{ {{\text{S}}_{1} , \ldots ,{\text{S}}_{\text{m}} } \right\} $$
(4)

The charge A to be paid by the user depends on the number of instances of VM requested and the retail price of the VM instance of VM types Vj (Eq. 5).

$$ {\text{A}} = \sum\nolimits_{{{\text{j}} = 1}}^{\text{m}} {{\text{R}}_{\text{j}} * {\text{S}}_{\text{j}} } $$
(5)

A federation is made up of a set of cloud service providers that build an alliance to provide a cloud service package. Mathematically it is represented as a subset of the set of cloud service providers F ⊆ P.

3.2 Revenue Sharing in Cloud Federations

Revenue sharing in cloud federations requires four steps: (i) calculation of the cost of operation (service provisioning), which depends on the CSPs that the jobs are assigned to; (ii) calculation of the total revenue and the total profit; (iii) maximizing the revenue and profit; and (iv) a method for calculating the revenue share.

Cost of VMs.

There is some cost associated with running the virtual machines at a CSP’s data center. The cost includes power consumption, operation cost, and maintenance cost. The cost for running same type of virtual machine may be different for different service providers depending on the geographical location as well as security and other provisions implemented by individual CSP [15, 26]. The cost of running a VM of type Vj at the data center of service provider Pi is represented as Cij.

The cost may also be affected by dynamic factors, like the current work load at the CSP’s data center. A CSP, who is not willing to accept many requests from the federation due to an internal high workload, assigns a price higher than the actual cost for the resource.

However, the retail price Sj is fixed, independent of which CSP within the federation is provisioning the resources.

This distinction between retail price and cost is important as it is used as a basis for calculating the profit for job requests within the federation. For each job request, the cloud broker receives the status of resource availability and cost from the CSPs.

Revenue and Profit Calculation.

The total revenue is calculated as the sum of the retail price of all the VM instances running at all the CSPs of a federation F. The total profit from a cloud service provisioning R is calculated similarly as the sum of the differences between the retail price and cost of all the VM instances running at all the CSPs of a federation F (Eq. 6).

$$ {\text{Revenue}}\left( {{\text{F}},{\text{R}}} \right) = \sum\nolimits_{{{\text{i}} = 1}}^{\text{n}} {\sum\nolimits_{{{\text{j}} = 1}}^{\text{m}} {{\text{R}}_{\text{j}} * {\text{S}}_{\text{j}} } } ;\quad {\text{Profit}}\left( {{\text{F}},{\text{R}}} \right) = \sum\nolimits_{{{\text{i}} = 1}}^{\text{n}} {\sum\nolimits_{{{\text{j}} = 1}}^{\text{m}} {{\text{R}}_{\text{j}} *\left( {{\text{S}}_{\text{j}} - {\text{C}}_{\text{ij}} } \right)} } $$
(6)

where \( S_{j} \) is the retail price set by the broker for a virtual machine of type V j , and \( C_{ij} \) is the cost of running a virtual machine of type V j at the data center of provider P i .

Revenue and Profit Maximization Through Federation Selection.

A job assignment is performed with the objective of maximizing the total revenue or the total profit of the federation PF. Mathematically, the maximization problem can expressed as:

$$ \max\nolimits_{{{\text{F}} \subseteq {\text{P}}}} {\text{Revenue}}\left( {{\text{F}},{\text{R}}} \right);\;\max\nolimits_{{{\text{F}} \subseteq {\text{P}}}} {\text{Profit}}\left( {{\text{F}},{\text{R}}} \right) $$
(7)

Due to the differences in the cost of service provisioning through different service providers, the profit for the federation varies for different combinations of CSPs provisioning the cloud service request. In order to maximize the total profit of the federation, it is desirable to bundle the cloud services from the top of a list, which lists service providers with available resources in ascending order of price imposed by them. Job requests, for which no services can be bundled due to lack of adequate available resources, need to be rejected.

Profit Sharing.

In order to continue working in cooperation within a federation, CSPs should be able to receive a fair share of the total benefits of the alliance. Thus, the question is: what is a fair way to divide the payoffs among the members of the alliance. Therefore, it is necessary to define fairness. One approach of defining fairness is to identify axioms that exhibit the properties of a fair payoff division. Lloyd Shapley [24] presents such axioms for a coalitional game in general and states that, the fairness is achieved, if each member of the alliance receives a payoff in proportion to its marginal contribution to the alliance. We apply these axioms to cloud federations:

Axiom 1 (Symmetry):

Two cloud service providers, who offer exactly the same (quality and quantity of) resources to the federation (i.e., alliance), are considered to be interchangeable and should receive the equal revenue share. Therefore, if two CSPs i and j are interchangeable in a federation of |F| CSPs and a job request R, then the revenue of both CSPs is equal:

$$ {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}} \right) = {\text{Revenue}}_{\text{j}} \left( {{\text{F}},{\text{R}}} \right) $$
(8)

where Revenuei(F,R) and Revenuej(F,R) represent revenues of CSPs i and j, respectively. Both CSPs are part of a federation F of |F| CSPs, handling a job request R.

Axiom 2 (Dummy Players):

A member CSP of a federation that has no resources available for the alliance is considered to be a dummy player and should receive zero benefits from the alliance. Therefore, if a CSP i contributes no resources to a federation of |F| CSPs and a job request R, then the revenue of CSP i is zero:

$$ {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}} \right) = 0 $$
(9)

where Revenuei(F,R) is the profit share of CSP i with respect to service provisioning of job request R in a federation F.

Axiom 3 (Additivity):

If it is possible to decompose a job request R, then it should be possible to decompose the revenues. Therefore, if a job request R can be decomposed into R1 and R2 in a federation F of |F| CSPs, then:

$$ {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}^{1} + {\text{R}}^{2} } \right) = {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}^{1} } \right) + {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}^{2} } \right) $$
(10)

where \( {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}^{1} + {\text{R}}^{2} } \right) \) is the revenue share of CSP i gained by the service provisioning of job request R (i.e., R1 + R2), while \( {\text{Revenue}}_{\text{i}} \left( {{\text{F}}, {\text{R}}^{1} } \right) \) and \( {\text{Revenue}}_{\text{i}} \left( {{\text{N}}, {\text{R}}^{2} } \right) \) are the revenue share of CSP i gained by the service provisioning of job request R1 and R2, respectively.

Shapley Value Method:

It is a method that satisfies the three axioms [12, 39]. It divides the revenue among the members of an alliance. In detail, it is calculated as:

$$ \upphi_{\text{i}} \left( {{\text{P}},{\text{v}}} \right) = \frac{1}{{\left| {\text{P}} \right|!}}\sum\nolimits_{{{\text{F}} \subseteq {\text{P}}}} {\left| {\text{F}} \right|!\left( {\left| {\text{P}} \right| - \left| {\text{F}} \right| - 1} \right)!\left[ {{\text{v}}\left( {{\text{F}} \cup \left\{ {\text{i}} \right\}} \right) - {\text{v}}\left( {\text{F}} \right)} \right]} $$
(11)

where ɸi(P,v) is the Shapley value of CSP i, and v is a function (v: 2 N → ℜ) that represents the worth of an alliance. The term [v(F ∪ {i}) – v(F)] represents the marginal value that CSP i adds to the alliance F, where \( {\text{v}}\left( {{\text{F}} \cup \left\{ {\text{i}} \right\}} \right) \) is the value of the alliance includes F and i, and \( {\text{v}}\left( {\text{F}} \right) \) is the value of the alliance F that does not include i. The term \( \left| {\text{F}} \right|!\left( {\left| {\text{P}} \right| - \left| {\text{F}} \right| - 1} \right)! /\left| {\text{P}} \right|! \) is used for normalized weighting for the different possible alliances of size |F| and the total number of possible alliance members |P|. \( \left| {\text{F}} \right| \)! represents all possible number of alliances that could be made before CSP i is added to the alliance and \( \left( {\left| {\text{P}} \right| - \left| {\text{F}} \right| - 1} \right)! \) represents the number of other possible alliance.

4 Simulation

4.1 Simulation Setup

For our simulations, five CSPs having homogeneous cloud resources (i.e., VMs) are considered. The specification of the VM type is based on the Amazon Web Service EC2 t2.xlarge. The retail price for the virtual machine is fixed as per AWS EC2 on-demand pricing for Seoul, South Korea as of May 30th, 2017. The details on the VM type specification and the retail price are shown in Table 1. For the simulation, we also consider a uniform cost for all VMs of all CSPs. As CSPs operate with profit margins at a level of 23% [25], we fixed the cost at a level of 80% of the retail price for all CSPs (Table 1). However, it has to be noted that the approach presented is applicable for scenarios with different cost of VM instances for different providers.

Table 1. Specification and cost of the VM instance for simulation.

Per scenario, multiple simulation runs were carried out with 100 job requests in each run. Each job request included different numbers of VM instances, but for simplicity reasons, we considered only one type of VM instances. The entire simulation experiment comprised simulation runs for four different demand scenarios that were created by varying the average size of job requests and the number of VM instances made available by the five CSPs. These scenarios are listed and briefly described in Table 2.

Table 2. Simulation scenarios.

4.2 Result and Analysis

As shown in Fig. 2, among the four scenarios considered in the simulation, only in one of the scenarios (Scenario 3), in which job sizes are small enough to be fulfilled by individual CSPs, profit could also be generated in absence of a federation. In every other scenario, the absence of a federation yields no profit. It is not unexpected, as no job request was small enough to be provisioned by a CSP without extending their resource capability beyond their limit. Thus, in absence of a federation, all job requests were dropped, thereby providing zero profit for all CSPs. The result of the simulation demonstrates that a group of CSPs can maximize their total profit by working within a federation.

Fig. 2.
figure 2

Comparison of the total profit for no federation and federations for four scenarios.

Table 3 depicts the Shapley values for each of the CSPs for all four scenarios (number of VM instances made available by each CSP) and the average job size. It indicates the value of the contributions given by each CSP in the federation. The Shapley values were calculated following Eq. 9 and averaging over all repeated simulation runs with 100 job requests per run.

Table 3. Individual CSP contribution (Shapley values) for all four scenarios.

As depicted from the result (Scenario 3 and Scenario 4 in Fig. 3 and Table 3), it is observed that the marginal contributions (Shapley values) for each CSP is not only dependent on the resources on offer but also on the size of the job requests. The Shapley values for Scenario 4 correspond to the resources made available, while Scenario 3 show equal values for all CSPs despite similar differences in resources made available. These equal values are not unexpected. Job requests for Scenario 3 were small enough, such that they could be fulfilled with available resources by any of the CSPs individually. For such job requests, the contributions by each CSP are equal, despite the differences in the number of available resources that the CSPs have on offer. No additional value could be created with surplus resources in that scenario. This result is acceptable and demonstrates the fairness property of the Shapley value method.

Fig. 3.
figure 3

Number of VM instances made available by each CSP and the marginal contributions (Shapley values) of each CSP for Scenario 3 and Scenario 4.

Furthermore, if the job requests are large, CSPs with a similar number of resources on offer are evaluated with similar Shapley values and, hence, similar revenue and, as the cost is fixed, similar profits. This is shown for Scenario 1 and Scenario 2 (Fig. 4 and Table 3). With regards to a large job request, these CSPs are interchangeable with each other. Therefore, they provide a similar marginal contribution to the federation. Hence, a similar evaluation of their contributions in the federation is justifiable and demonstrates fairness of the method.

Fig. 4.
figure 4

Number of VM instances made available and the profit shares of CSPs for Scenario 1.

5 Discussion and Conclusion

As seen from the simulation results, if CSPs work independently, any job request, which comes to a CSP and requires resources beyond the CSP’s current free resources, has to be rejected, leading to a loss of revenue (Fig. 2). In the case of CSPs working in a federation, the same job request can be accepted due to resource aggregation from multiple CSPs, thereby leading to additional revenue. This demonstrates that a federation can play an important role in maximizing the total revenue of CSPs. Furthermore, if resources from all CSPs needed to be aggregated to fulfill a job request (Table 3 and Fig. 4), the simulation result showed that the profit share calculated with the Shapley value method is close to the profit share calculated with a basic method (i.e., the fraction of resources made available), which also demonstrate fairness of the Shapley method.

In addition to this, if job requests can be fulfilled by any of the CSP individually, unlike to the basic method, in which the revenue varies based on the resource made available by the CSP, the Shapley model yields an equal revenue share for each of the CSPs independent to the number of resources made available. The marginal contributions of all CSPs are equal. This essentially demonstrates the feature of the Shapley model. It provides the desired property of fairness by considering the contribution of the CSP to a job request.

The simulation results also demonstrate that two CSPs making an equal number of VM instances available to the federation receive an equal revenue share, if the revenue is calculated following the Shapley value method. This also exhibits fairness.

Considering these results, we can conclude that a revenue sharing model based on the Shapley value method can provide an increased total revenue for CSPs in cloud federations compared to CSPs working independently. The revenue sharing model based on Shapley values provides a fair distribution of revenues to member CSPs in cloud federations.

We believe that both CSPs and a cloud federation can benefit from a fair revenue sharing model. For individual CSPs, the assurance of receiving a fair share of the revenue according to their contribution to fulfilling a job request encourages them to join and continue cooperation within the federation. For the federation, the Shapley value method provides a way of distributing revenue to federation members, which have been generated from an increase in the overall resource utilization. These benefits improve the stability of a federation.

Our Future work will address technical aspects of implementing the Shapley value method as well as making our current investigation more realistic. This includes refined scenarios, a system architecture, the consideration of selfish-behavior of CSPs.