Keywords

5.1 Topic Definition

Cloud computing has widely been accepted as an efficient way of using computing resources. It lowers the cost of computing services, provides access to virtually unlimited resources, and allows for flexible charging methods (Jeferry et al. 2015). Nonetheless, there are resource limitations and cost-related shortcomings (Goher et al. 2018). For instance, cloud computing services could still be over-provisioned or under-provisioned (Goiri et al. 2012), which is due to the volatility of demand for computing resources and anti-competitive externalities that exist in the market (Altmann and Kashef 2014; Mohammed et al. 2009). In order to allow cloud providers and cloud customers to deal with this situation, we present a comprehensive cost model comprising relevant cost factors and an economic model underlying the various cloud deployment models.

5.1.1 Public Clouds, Private Clouds, and Interconnected Clouds

As cloud users can select among various cloud deployment models, which come with different costs and benefits, an understanding of those costs and benefits is essential for making an optimal selection decision. In order to outline the difference in costs that cloud users face, we distinguish three major types of cloud deployment models: public clouds, private clouds, and interconnected clouds. While public clouds represent clouds that anybody can use as a customer (e.g., Amazon EC2) for a service charge (Altmann et al. 2010), access to a private cloud is limited to the owner of the cloud. Private clouds denote firms’ private data centres and host their security-critical services, meeting the firms’ computational needs. The data centre is organized using cloud computing technology, as it allows for more efficient organising of the information technology resources of the firm. Public clouds are not necessarily interoperable, as they might have been built with proprietary cloud technologies (Breskovic et al. 2013a, b; Gebregiorgis and Altmann 2015; Maurer et al. 2012). A cloud user, who wants to use several public clouds, would need to use the standards of each cloud. Interconnected clouds are combinations of private clouds and public clouds (Rochwerger et al. 2009), which are achieved technically by making clouds interoperable, giving them the same cloud interfaces. Due to this interoperability, virtual machines can easily be migrated between clouds owned by different cloud providers. It allows users of a cloud to take advantage of the capabilities of other clouds in addition to those of their primary cloud providers (Haile and Altmann 2018). Considering the ownerships, standards, and location of the interconnected clouds, different types of interconnected clouds can be distinguished. A few examples are given in Fig. 5.1.

Fig. 5.1
figure 1

Example of four interconnected clouds (i.e., private intercloud, hybrid cloud, federated hybrid cloud, and federated cloud), being composed of private clouds and public clouds

Overall, eight types of interconnected clouds can be distinguished: public interclouds, private interclouds, hybrid clouds, federated clouds, federated hybrid clouds, hybrid interclouds, federated hybrid interclouds, and federated interclouds.

Distinguishing interconnected clouds from the ownership perspective, clouds can be classified into interclouds and federated clouds. An intercloud is owned by a single provider (e.g., Amazon Web Services), while the clouds of a federated cloud (type 7 in Table 5.1) are owned by several providers. The motivation of interclouds is mainly fault tolerance (e.g., guaranteed availability of customer applications through reliable multi-site deployments (Petcu 2014)) and quality of service (e.g., latency reduction) through a larger computing resource base and their wide geographical distribution (Hassan et al. 2014). An intercloud can be private (type 4) or public (type 5). If an interconnected cloud is composed of a private cloud and one public cloud, it is called hybrid cloud (type 3). If an interconnected cloud is composed of several private clouds and one public cloud, it is called hybrid intercloud (type 6). It is used by firms, if their demand for computing resources is temporarily in excess of the capacity of their private clouds and the excess demand can be covered by a public cloud (Bossche et al. 2013). With respect to federated clouds, the cloud providers participating in a cloud federation have reached an additional service level agreement, called federation service level agreement (FSLA), for cooperating on deployments of customer applications. Federated clouds enable marketplaces and trading of standardized goods (Altmann et al. 2010; Maurer et al. 2012). They also enable small cloud providers to collaborate and gain access to an increased number of cloud infrastructure resources and to benefit from the economies of scale through the aggregation of both requests and resources (Haile and Altmann 2016a, b; Kim et al. 2014). An interconnected cloud is called federated hybrid cloud (type 8), if the interconnected public clouds signed an FSLA and the private cloud accesses the federated clouds for additional cloud services. The federated hybrid cloud model is an extension to the hybrid cloud model. If the private cloud is an intercloud, the model is called federated hybrid intercloud (type 9). The last model is the federated intercloud (type 10), which does not comprise a private cloud. All ten interconnected cloud deployment models are shown in Table 5.1, which presents them according to cloud ownership, access rights, and cloud standards.

Table 5.1 Ten types of cloud deployment models

When it comes to the adoption of any of those ten cloud deployment models, companies need to consider various factors including application complexity, available technology options, available support, security provisions and, more importantly, the cost.

5.1.2 The Need for Detailed Cost Models for Clouds

For many companies, the migration of the workload to the public cloud has helped them achieve rapid deployment of their applications and reduce operational costs for their data centres (Rayport and Heyward 2009). A recent article by McKinsey states that a company using a traditional computing model can potentially make savings (both labor and non-labor combined) of 9% by adopting a private cloud, and up to 61% by adopting a public cloud (Gu et al. 2018). Current research already indicates that further reduction of the cost of cloud service provisioning is possible through cloud federations (Altmann and Kashef 2014; Aryal and Altmann 2018; Goiri et al. 2012). However, in order to make informed decisions on a migration to clouds (Kauffman et al. 2018; Khajeh-Hosseini et al. 2012; Truong and Dustdar 2010), details about the costs of clouds are needed. An in-depth cost analysis of the various options, which affect the overall cost of adopting an appropriate cloud deployment model, can help. The cost analysis can comprise calculating different economic values (e.g., the Net-Present-Value, the Return-on-Investment, the Discounted-Payback-Period, and the Benefit-to-Cost-Ratio), which are essential for any business decision (Klems et al. 2008), and, herewith, would enable organisations to determine which cloud deployment model is most beneficial.

Due to its importance for cloud deployment decision making, cost models have gained significant attention of the research community in recent years.

5.2 State of the Art in Cost Models

Reviewing previous literature on cloud cost models, which has been published between year 2005 and year 2019 and was found searching Google Scholar with combinations of search terms ‘cost’, ‘cost model’, ‘cloud’, ‘cloud computing’, ‘grid’, ‘cost factor’ and ‘cost-benefit’, suggests the need to consider 21 cost factor groups for estimating the cost of IaaS services applicable for different cloud deployment models. The identified cost factors and their classifications are presented in Table 5.2. The classification of the 21 cost factors comprises six main categories (i.e., electric power, system infrastructure, software, human resources, business premises, and cloud services). These cost factor groups are also classified according to the cloud deployment model, which need to consider this group of cost factors.

Table 5.2 Cost factors associated with cloud deployment models

A detailed description of each of the categories and groups of cost factors is given in the following subsections.

5.2.1 Cost Factor Category: Electric Power

Electric power consumption is one of the major factors contributing to the cost of clouds. A cloud consumes power basically for two activities: (1) powering data center devices such as routers, switches, gateways, servers, and storage devices (Alford and Morton 2009; Armbrust et al. 2009; Kondo et al. 2009; Opitz et al. 2008; Patel and Shah 2005; Risch and Altmann 2008; Tak et al. 2011); and (2) operating HVAC cooling system devices (Alford and Morton 2009; Armbrust et al. 2009; Patel and Shah 2005; Opitz et al. 2008; Tak et al. 2011). In order to have the precise estimations, it is necessary to consider the power consumption of each device under different conditions (i.e., when it is running at no load, average load, and full load) (Opitz et al. 2008).

5.2.2 Cost Factor Category: System Infrastructure

The cost associated with acquiring a hardware system infrastructure for in-house use is referred to as system infrastructure cost. System infrastructure cost can be classified into two groups. The first group includes the cost of acquiring computing equipment such as servers and storage devices for in-house use (Alford and Morton 2009; Altmann and Rohitratana 2010; Kondo et al. 2009; Opitz et al. 2008; Risch and Altmann 2008; Tak et al. 2011). The second group includes the cost of acquiring network equipment such as routers (Alford and Morton 2009; Altmann and Rohitratana 2010; Tak et al. 2011). For this cost of system infrastructure, as suggested by Opitz et al. (2008), it is important to consider the time period (i.e., depreciation period), during which this equipment can be used. It is a normal practice for this equipment to have a three-year economic lifetime.

5.2.3 Cost Factor Category: Software

The software cost factor category includes the cost incurred in purchasing software licenses for in-house use. In particular, the operations of data centers include three groups of software licenses. The first category may be referred to as basic server software licenses, which include operating system software licenses and licenses for system administration such as backup system software (Alford and Morton 2009; Altmann and Rohitratana 2010; Patel and Shah 2005; Tak et al. 2011). Similarly, the second group of licenses includes commercial middleware software that is required for operating a cloud (Opitz et al. 2008; Patel and Shah 2005). The last group includes licenses for application software, which provides value directly to customers. An example is a software for enterprise resource planning (Alford and Morton 2009; Altmann and Rohitratana 2010; Opitz et al. 2008; Tak et al. 2011). It is also important to note that depending on the vendor, software may be purchased only under certain licensing policies (e.g., perpetual license, license that require periodic renewal, and license that charge according to the number of end users). Due to these different licensing policies (Altmann and Rohitratana 2010), the cost can vary widely.

5.2.4 Cost Factor Category: Human Resources

The human resources cost category includes salaries to be paid for technicians, who maintain the hardware infrastructure (Alford and Morton 2009; Armbrust et al. 2009; Opitz et al. 2008; Tak et al. 2011), technicians, who maintain software applications (Alford and Morton 2009; Patel and Shah 2005; Tak et al. 2011), and technicians, who provide support services (Alford and Morton 2009; Kondo et al. 2009; Opitz et al. 2008; Tak et al. 2011). Due to the differences in economic conditions, cost of living, and the availability of labor in different countries, this cost category is largely determined by the geographical location of a data center.

5.2.5 Cost Factor Category: Business Premises

The business premises cost category includes the basic costs involved in setting up the basic facilities required for establishing an in-house data centre (private cloud). Important cost factors include (1) the cost of purchasing or leasing the data centre facility (Armbrust et al. 2009; Patel and Shah 2005); (2) the cost of all installations that ensure security and reliability of the data center such as HVAC cooling systems, physical security systems, server racks, and other non-electronic devices (Alford and Morton 2009; Patel and Shah 2005); and (3) the cost for cabling and networking required for the operation of the data centre (Alford and Morton 2009; Patel and Shah 2005).

5.2.6 Cost Factor Category: Cloud Services

This category of cost factors includes all intangible cost items directly related to the use of cloud services. They are classified into seven groups. One of the groups comprises the server usage cost (e.g., per hour price of virtual machine (VM) instance time duration) (Hajjat et al. 2010; Hwang et al. 2013; Khajeh-Hosseini et al. 2012; Kondo et al. 2009; Risch and Altmann 2008; Truong and Dustdar 2010). The second group includes cost items related to the cost of storage (Armbrust et al. 2009; Hajjat et al. 2010; Hwang et al. 2013; Khajeh-Hosseini et al. 2012; Kondo et al. 2009; Opitz et al. 2008; Risch and Altmann 2008; Tak et al. 2011; Truong and Dustdar 2010). The cost of Internet service for the firm is another cost group (Hajjat et al. 2010; Kondo et al. 2009). The cost of data transfers into the cloud and the cost of data transfer out from the cloud make two more groups (Armbrust et al. 2009; Hajjat et al. 2010; Hwang et al. 2013; Khajeh-Hosseini et al. 2012; Kondo et al. 2009; Opitz et al. 2008; Risch and Altmann 2008; Tak et al. 2011; Truong and Dustdar 2010). As another cost factor group, the cost associated with the transfer of data between clouds has been identified (Altmann and Kashef 2014). This cost group has not received much attention in literature, although it is important in the case of interconnected clouds. Its significance can be seen from the fact that Amazon charges higher prices for data transfer between its clouds located in different regions than for data centers located in the same region. The last cost factor group is the deployment cost. This cost group had also not received much attention in previous literature. Although the probability of VM migrations is low in case of hybrid cloud deployment types, for interconnected clouds, this cost factor group can become significant. Various events may trigger new service deployments that are more economically efficient than the existing deployments. Deployment cost may be determined as the number of deployments multiplied by the cost of migration for each deployment.

5.3 Avenues for Future Research: Economic Models for Federated Clouds

Interconnected clouds, in particular, cloud federations, have been considered as a way for cloud providers to address the limitations of clouds and to decrease the cost of service provisioning by means of resource aggregations and reliable multi-site deployments. Despite these significant promises, we cannot find any cloud federation in operation in the commercial market. Our review of the cloud federation literature (Aryal and Altmann 2017; Coronado and Altmann 2017; Hassan et al. 2014; Jeferry et al. 2015; Samaan 2014; Wang et al. 2012) identified only a few notable causes. In particular, a lack of proper economic models has been identified as an important hindering factor in the adoption of cloud federations (Breskovic et al. 2011; Haile and Altmann 2015).

These economic models can incentivize cloud providers for forming and operating federations and for sharing revenue. As revenue sharing is directly linked to how resources are shared among federation members (Roth 1988), an efficient solution should specify jointly how members of a cloud federation share the infrastructure resources and the revenue generated through the service provisioning with shared resources. The solution needs also to connect these algorithms for resource sharing (i.e., service placement) and revenue sharing (i.e., business logic) with an accounting system. Appropriate algorithms for revenue sharing are required to incentivize properly the federation members for fulfilling the service requests that they should serve and the service requests that they bring into the federation. It also requires considering a large number of geographically distributed providers offering heterogeneous services with varying QoS guarantees (Aryal and Altmann 2017; Aryal and Altmann 2018). Despite this interesting challenge, only very few researchers have started working on these economic models related to service placement and revenue sharing in federated clouds and have proposed algorithms (Aryal et al. 2019).

Considering the need for algorithms for service placement and revenue sharing, a system architecture for a cloud federation platform and a use case for applying an economic model in cloud federation deployments can be envisioned as shown in the following figure (Fig. 5.2). The economic model in this architecture is implemented through three modules: service placement, accounting, and revenue sharing.

Fig. 5.2
figure 2

Use case for applying economic models for cloud federations

The use case shown in Fig. 5.2 highlights the workings of the system architecture. It illustrates that a cloud service user in need of application deployment in the cloud initiates an application deployment request (step 1) through a cloud provider (Cloud Provider 1), who is a member of a cloud federation. The cloud federation platform receives the request through the provider management module (step 2) and triggers the service placement module within the economic module for determining the service placement plan based on the available resources (step 3 and step 4) by identifying the best possible combination of the federated cloud resources (step 5 and step 6). The service nodes of the customer application get deployed as per placement plan (step 7 and step 8). The accounting module within the economic model records the transaction and resource consumption in the customer account, using the service provisioning details for the request (step 9). Finally, the revenue sharing module allocates the earned revenue as per the agreed sharing rules (step 10).

As not much research has been performed on the details of economic models for federated clouds, future research is needed to fill this research gap. Researchers should seek to propose economic models for the governance of cloud federations that incentivize cloud providers to form and sustain the operation of cloud federations. The architecture shown in Fig. 5.2 indicates the workings of the modules of such an economic model. These economic models provide guidance for the effective utilization of provider resources in serving customer requests for cloud services and distribute the revenue generated in an appropriate way to the federation members. In particular, they could help in the selection of an optimal set of cloud resources to host application service components and provide a fair, stable, and motivating revenue sharing scheme for cloud federation members with a better return on investments.