Proceedings of IEEE CCIS2012
Modeling the Interactions between Cloud Service Providers Dimosthenis Kyriazis Department of Digital Systems University of Piraeus, 80 Karaoli & Dimitriou Str, 185 34, Piraeus, Greece
[email protected] Abstract: Cloud computing is becoming a widely adopted underlying technology for the provision of different types of services. As a paradigm building on a set of combined technologies, it enables service provision through the commoditization of IT assets and on-demand usage patterns. Within the application domain, services move away from the monolithic approach into an Internet-scale composite one by exploiting data, atomic services and infrastructures. In this paper an approach is presented for identifying and modeling the interactions between service providers. The presented approach can be exploited during the selection process for composite services based on various metrics that define the corresponding end-to-end Quality of Service (QoS). Keywords: Cloud Computing, Composite Services, Business Relationships
1 Introduction Nowadays, cloud computing refers to a computing paradigm whose foundation is the delivery of services and ICT assets [1], often denoted as XaaS (Everything as a Service). The term refers to an increased number of cloud-based resources and services provided over the Internet, with the most common examples, following the SPI model [2], Software (SaaS), Platform (PaaS) and Infrastructure (IaaS) as a service. Various characteristics, such as virtualization of hardware, rapid service provisioning, scalability, elasticity, accounting granularity and cost allocation models enable Clouds to efficiently adapt resource provisioning to the dynamic demands of Internet users. As the cloud service model matures and becomes ubiquitous, service-based applications are amongst the first being deployed in such platforms. In the majority of the cases, these applications move away from the monolithic approach towards a paradigm that emphasizes modular design, giving rise to the wider adoption of the cloud service model. Since these applications consist of application service components [3], they are considered to be composite services and in many cases referred as workflows in the literature even though the term workflow includes also the orchestration of the services [4]. These application service components provide specific functionality, contributing to the overall application’s one, and may be offered by different providers. There has to be noted that this distributed paradigm is also
applied across the cloud service stack since besides service components, infrastructure (e.g. networking or storage resources) may be offered as a service within the overall applications. A representative example refers to a video rendering application which consists of service components (i.e. shaders compilation, textures compilation, rendering) but could also require the provision of a storage service to for the output video file. Thus, Future Internet applications offered through cloud environments often impose the need to engage more than one providers that offer the corresponding service. Moreover, one has to consider that the need for dependability (as one of the main Future Internet Architecture Design Principles [9]) is fundamental for the user needs, while it has been noted that focus of cloud computing is the user experience [10]. In this context, service selection should account for the specific requirements with respect to the Quality of Service (QoS). In the case of composite services, additional challenges arise given that the users set their requirements for the (overall) end-to-end QoS and not for specific service types, as well as that the delivery of the composite service may be provided across a federation of providers. To address these challenges, one needs to identify whether and to what extend the providers have business relationships, which may be Cooperating, non-Cooperating or even Antagonistic, Cheating, or Malicious. These relationships affect the selection process since the QoS metrics of a service provider may change based on a selection of another provider. In many occasions, a service provider may alter his offered services’ QoS values based on the selection of another service provider depending on their business relationships. This paper discusses and presents a modeling approach of the interactions and business relationships of service providers along with a proposal providing metrics for defining a service provider “friendliness” based on the relationships that this service provider has with other ones. The aforementioned metric can be used by QoSbased selection mechanisms to take into account business relationships during the selection process and meet the user’s end-to-end QoS requirements for composite services and applications. The remainder of the paper is structured as follows: Section 2 presents related work in the field of interactions between different entities in cloud environments, while the next section, entitled “Cloud Providers Interactions Identification and Modeling”
Proceedings of IEEE CCIS2012
introduces the concept of Business Relationships and provides a modeling approach for them while a proposal for defining a metric to characterize a service provider’s friendliness, is also included. The paper concludes with a discussion on future research and potentials for the current study.
directed edge on the problem’s graph from a service provider A to a service provider B. The source of the edge is the provider that stimulates the interaction and the destination is the provider that alters its service parameters in response to the selection of the source. A-B Interaction
2 Related Work While there are various ontologies for capturing the information regarding the cloud entities and the corresponding offered services and resources, such as the ones discussed in [5], [6] and [7], only a few approaches exist for modeling and identifying the interactions between different providers. Authors in [8] present architecture service models based on the Amazon Web Services cloud environment [ref]. The main contribution of the paper is that end users are able to create services utilizing different offerings of Amazon (e.g. S3, SQS, SimpleDB, EC2, etc). Authors in [9] propose a usage model that can be applied to all cloud providers. Based on this model they define an abstract layer that is a generalization of the providers, thus enabling provider-independent service development. Authors in [10] present models of a cloud computing architecture to implement cross-cloud system management, allowing for different providers to aggregate their resources following pre-defined agreements. An interesting approach is presented in [11]. Authors propose a conceptual model (represented as a UML class diagram) that enables identification of interactions between service providers and infrastructure providers in order to provide an execution environment and deploy services on top of infrastructure services. The difference between these approaches and the presented one in this paper lies on the fact that these approaches do not tackle the issue of strategic relationships between different providers, but only model and identify the corresponding interactions. Furthermore, they do consider monolithic applications and not composite services for which different offerings from the service providers according to their relationships should be taken into consideration during a QoS-oriented service selection process.
3 Cloud Providers Interactions Modeling Following, an approach for identifying and modeling the interactions between cloud service providers as well as for characterizing a service provider based on these interactions is described.
Service Provider A
Service Provider B
Figure 1 An interaction between two service providers
In the example presented on the above figure (Figure 1), service provider A triggers a change to provider’s B QoS parameters and thus, an edge from provider A to provider B is depicted. In case that the selection of provider B changes the parameters of provider A, a second edge with the opposite direction would be required. The above modeling is characterized “external” as it puts the stimulator instead of the actual affected provider in the center of attention. On the whole service instances space, the instances that affect a great number of other instances will appear as the source of numerous vectors and as a result their total effect on other instances can be measured. The opposite approach, deriving all edges from the affected service instance, has the disadvantage of taking the focus off the influential service instances and it is not suitable for a forward-looking heuristic algorithm.
3.2 Measuring the Influence of an Interaction In this section a metric that rates the influence of an interaction from various perspectives and which can be seen as an additional QoS parameter during the service selection process is proposed. There are various parameters of interest that are being considered by QoSoriented service selection algorithms such as cost, availability, response time, etc. The metric capturing the interaction influence should cover the corresponding parameters distinct influence aspects, i.e. the influence on each parameter (e.g. influence on cost, on availability, on response time). These metrics are all derived from the following equations. Denoting as the metric for a cloud provider interaction influence (CPII), where trigger refers to the service provider that triggers an interaction, affected refers to the service provider that alters its QoS parameters, and levels refers to the set of services which are being affected / influenced by the interaction. The CPII metric consists of two addends, each one representing two distinct parts of an interaction’s influence:
3.1 Modeling Interactions Firstly, one of the issues that has to be resolved is how the interactions are modeled on the service provider’s space. The proposed approach looks at strategic relationships from an external perspective as it focuses on how the selection of a provider affects other providers. As a result, each interaction is modeled as a
3.3 Immediate Influence of an Interaction The first addend that we define here is the Immediate Influence (II), which is reflecting the effect on the QoS
Proceedings of IEEE CCIS2012
parameters of a service provider when a triggering provider has already been selected for obtaining specific services. The Immediate Influence needs not only to take account of the actual QoS parameters changes but also to express the potential of the original values. Application
Service 1
A
B
Interaction with immediate influence
Service 2
D
C
Interaction with immediate and future influence
E
providers that improve their parameters in the exact same way. As a result, their II values will be identical. However, taking into consideration the interactions from service provider C, one would conclude that interactions A-C is better comparing to the interaction A-B not because of immediate improvements but in terms of future benefit. If all of the providers offering service 3 advertise better (in terms of cost for example) QoS parameters then the CCPI metric for the interaction A-C must be higher than the A-B one. Nevertheless, not all interactions should be taken into account when calculating the influence of a future interaction.
F Application
Service 3
G
H
Service 1
A
B
C
Service 2
D
E
F
Service 3
G
H
I
I
Figure 2 Interactions with Immediate and Future Influence
In the above example (Figure 2), service provider A influences both service providers E and F. In order to conclude on the immediate influence of each interaction, the changes of the QoS parameters for providers E and F need to be considered. Denoting as II(trigger, affected) the immediate influence of an interaction:
where NewValue and OldValue are the corresponding QoS parameters values of the affected service provider, while MinValue and MaxValue refer to the minimum and maximum value of the specific QoS parameter as advertised by the service providers for a specific service. The first fractional factor represents the relational change in the parameter’s value. Higher changes in these values would mean additional benefit from this interaction. The second factor has a double role. The first one is to amplify the II values of those service providers that have already advertised QoS parameters values close to maximum for the specific service. The second is to express the user’s interest on that specific parameter by multiplying with a slope factor that will be better clarified later on. Based on this equation, the values of the II metric are positive when the service parameter is improved due to the interaction of the providers and negative otherwise. In case of no changes, II equals to zero.
3.4 Future Influence of an Interaction Besides the immediate influence, one needs to consider the future ones that affect a non-monolithic application service selection process. As depicted in figure 2, there may be an additional service offered by the corresponding providers. Concluding to the CPII for both interactions between service provider A and service providers B and C, let us assume initially that B and C are two identical service
Figure 3 An indifferent interaction on Future Influence calculation
Figure 3 adds to figure 2 a new interaction from provider F to provider C. Given that the future influence of an interaction captures the future potential of the aforementioned interaction, the relationship A-F should not consider the F-C, given that the source provider is actually selected. As a consequence, the fact that the provider F can actually improve the QoS parameters of another provider for Service 1 is indifferent to interaction A-F as interaction A-F requires that provider A is selected. Additionally, any interactions of service provider F with providers for other services for which the selection has already taken place should be discarded as they do not influence the selection process. There has to be noted that this future influence is not restricted to a single service. On the contrary, any of the providers of Service 3 may also have future influencing interaction that should be considered. An interesting issue that should be examined refers to the weight of future influence compared to immediate influence for an interaction. On the previous example, assuming that providers E and F have equal initial QoS parameters, and that the interaction A-E is greatly beneficial to provider E while the relationship A-F is not such beneficial for the QoS parameters of provider F, the problem that arises is how to compare a relationship like A-E with greater immediate influence to a relationship like A-F with decreased immediate but great future influence. The more choices there are in the future services, the harder should it be to create a future influence comparable to the immediate one. On the other hand the future influence becomes more important when the number of affected services in a given set of possible interactions increases. Denoting as FI(affected,
Proceedings of IEEE CCIS2012
levels) the Future Influence of an affected provider towards a set of different services: [ ∑
]
(
)
{
[
] [
]
[
]
[
]
where remLevels is the set (levels-level(affected)) that represents the remaining services that FI is calculated on, Num[] refers to the current number of service providers in a given set of services, and adj(affected,remLevels) is the set of adjacent to the affected providers for a specific service. Based on the above equations, FI is a recursive procedure that requires the calculation of all future relationship’s CPIIs. This calculation is bounded inside the affected provider’s interactions to different services for which providers have not already been selected. Fbpositive and Fbnegative represent the FI balance between positive and negative FIs and amplify those that outvote, diminishing the minority’s relationships future influence so as not to affect the FI metric by isolated, possibly malevolent, relationships. These balancing factors multiply accordingly each positive or negative CPII. To achieve the latter, Fbalancing is calculated as the number of each service’s (negative or positive) interactions divided by the total number of interactions. Following the balancing process for each subsequent CCPI, the corresponding results are accumulated and the outcome is divided by a new balancing factor. As described previously, this balancing factor actually represents the relation between each interaction’s immediate and future influences. By halving the current number of service providers, the importance of FI is decreased. This decrease is greater during the service selection of the first service of an application and becomes smaller as the services space is reduced. The latter enables immediate influences to be taken in consideration with greater weights when making early influence calculations, while when the choices diminish, future influence becomes more and more important. From another perspective, this division factor represents the exact number of future interactions required to surplus the immediate influence. Thus, better results appear when this number is halved equal to half the possible future interactions and that is the reason behind division by two.
3.5 Cloud Provider Friendliness Based on the above, the CCPI metric reflects the actual value of an interaction between different providers. It will be further on used as a basis to develop a well performing heuristic function that defines the friendliness of a service provider based on the corresponding interactions. This heuristic function moves the focus of interactions to the service providers and its main goal is to characterize the providers according to their potential within an application that consists of different services. Nevertheless, the introduction of this new metric, namely Cloud Provider Friendliness (CPF), should only take into account specific interactions. Application
Service 1
A
B
C
Service 2
D
E
F
Service 3
G
H
I
Figure 4 Cloud Provider Friendliness
In the example in Figure 4 the CPF metric will provide information on whether provider D or E is the most appropriate one to be selected for service 2. The metric considers the CPII of each provider. In the above example, providers D and E offer services with similar QoS parameters - with provider E being overall slightly better, while both providers interact with other ones which are identical and are influenced in the exact same manner from D and E. Additionally, provider D can be influenced from provider H. Taking into account the relationship H-D, provider D appears to be the better future choice. However, provider E may give better QoS parameters and provide equal future expansion potential. Given that the service selection for service 3 may not be provider H, the CPII metric is indifferent of the triggering provider’s parameters. Based on this, provider E is the preferable choice for service 2. To summarize, the calculation of Service Provider Friendliness should be unaware of any strategic relationships that can influence this provider and should only take account of providers that can be influenced. Another interesting issue that reappears on CPF as it did in CPII is how providers with mixed type influences can be tackled. In the following figure (Figure 5), provider A influences all providers offering service 2, with CCPI values for example -10, 3, 3 accordingly. Provider A actually has good future strategic potential, even though it can be destroyed by a single negative one.
Proceedings of IEEE CCIS2012 Application
Service 1
A
B
C
Service 2
D
E
F
Service 3
G
H
I
Figure 5 Handling mixed types of Strategic Relationships
In order to minimize the minority’s effect, balancing factors need to be used again that should take account of how positive and negative influences are distributed. Based on these, the Service Provider Friendliness (denoted as CPF) is: ∑
̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅̅)
(
[
]
{
[
] [
]
[
]
[
]
where provider is the service provider for which the CPF is calculated, levels is the set of services within an application for which the CPF is calculated, curLevel is the current service, Affected Providers is the number of adjacent to providers in the current level, Mean CPII is the arithmetic mean of CPIIs for the affecting interactions only in the current level, and the Balancing Factors are calculated as in FI, accumulating CPIIs per service. To calculate the CPF for a service provider, each provider’s interactions are examined on a per service basis. For each service within an application, each interaction CPII is balanced and the arithmetic mean value of the results is calculated. In order to express that more interactions with the same mean CPII are better than fewer ones, the actual number of the affected services per service is multiplied. The final outcome is calculated as the average mean value for each of the affected services (i.e. levels).
5 Conclusions Cloud environments have not yet adopted an effective scheme that will facilitate end-to-end QoS provisioning for Internet-scale composite applications [12]. Accounting for the particularities of clouds and such applications, this paper presents an approach for
modeling the interactions between cloud service providers. Furthermore, a metric (namely Service Providers Friendliness) has been introduced that characterizes the service providers and which can be used by QoS-oriented service selection mechanisms for applications consisting of application service components of different types. Besides, the proposed approach enables the adoption of different business models since it allows for the evaluation of alternative strategies (e.g. different QoS parameters being published by the interacting providers) and monitoring any changes / violations that may occur, which will have an important impact on the strategies, methodologies, and structure of business processes.
References [1]
A. Lenk, M. Klems, J. Nimis, S. Tai, T. Sandholm, “What's inside the Cloud? An architectural map of the Cloud landscape”, ICSE Workshop on Software Engineering Challenges of Cloud Computing, Washington, DC, USA, 23-31, 2009 [2] P. Mell, T. Grance, “NIST Definition of Cloud Computing”, Sp. Publication 800-145, http://csrc.nist.gov/publications/nistpubs/800145/SP800-145.pdf, 2011 [3] D. Kyriazis, R. Einhorn, I. Furst, M. Braitmaier, D. Lamp, K. Konstanteli, G. Kousiouris, A. Menychtas, E. Oliveros, N. Loughran, B. Nasser, “A Methodology for engineering real-time interactive multimedia applications on Service Oriented Infrastructures”, IADIS Applied Computing, Timisora, Romania, 2010 [4] M. P. Papazoglou, D. Georgakopoulos, “Serviceoriented computing”, Communications of the ACM, 2003 [5] T. Han, K. M. Sim, “An Ontology-enhanced Cloud Service Discovery System”, International MultiConference of Engineers and Computer Scientists (IMEC), 2010 [6] D. Bernstein, D. Vij, “Using Semantic Web Ontology for Intercloud Directories and Exchanges”, International Conference on Internet Computing (ICOMP), 2010 [7] L. Youseff, M. Butrico, D. D. Silva, “Toward a Unified Ontology of Cloud computing”, Grid Computing Environments Workshop (GCE), 2008 [8] J. Varia. “Cloud architectures,” Amazon Webservices, 2008. [9] T. Harmer, P. Wright, C. Cunningham, R. Perrott, “Provider independent use of the cloud,” 15th International Euro-Par Conference on Parallel Processing, 2009 [10] R. Dodda, C. Smith, A. Moorsel, “An architecture for cross-cloud system management,” 2nd International Conference on Contemporary Computing (IC3), 2009 [11] L. Wang, L. F. Pires, A. Wombacher, M. J. Sinderen, C. Chi, “Stakeholder Interactions to Support Service Creation in Cloud Computing”, Proceedings of the 2010 14th IEEE International Enterprise Distributed Object Computing (EDOCW), 2010 [12] Cloud Computing Expert Group Report, “The Future of Cloud Computing”, European Commission, http://cordis.europa.eu/fp7/ict/ssai/docs/cloud-reportfinal.pdf, 2010
