Rafael Brundo Uriarte
email: rafael.uriarte@imtlucca.it

Francesco Tiezzi
email: francesco.tiezzi@unicam.it

Rocco De Nicola
email: rocco.denicola@imtlucca.it

Rafael Brundo Uriarte

Dynamic SLAs for Clouds

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The cloud paradigm is inherently dynamic from both the consumer and the provider perspectives. From the provider's standpoint, new resources are added and removed on-the-fly, whilst service requests and prices vary over time as the pay-per-use model is employed. From the consumer's perspective, instead, the requirements may vary considerably when, e.g., clouds are used to outsource internal services or to complement the computing capacity through a hybrid cloud. Such dynamism might change providers and consumers requirements during the service provision period. Providers might need to change the agreements, e.g. to avoid the violation of agreements and to maximise revenues by serving consumers willing to pay for immediate use of the service [START_REF] Galati | Designing an SLA Protocol with Renegotiation to Maximize Revenues for the CMAC Platform[END_REF]. On the other hand, consumers may modify the service, e.g. to respond to unexpected demands, to extend the expiration date of a contract or to change the amount of resources to be provided.

Clouds commonly use Service-Level-Agreements (SLAs) to regulate the provision of services. A SLA is the formalisation of the service provision characteristics, which are composed of obligations, rights and guarantees for the involved parties. In clouds, where consumers entrust crucial data and processes to other parties, SLAs are necessary and reflecting cloud's dynamism in contracts is a crucial open issue. The need for dynamicity can be perceived by considering a situation in which a cloud provider has overbooked its resources and the load unexpectedly raises. In such case, the provider to avoid breaching SLAs, paying fines and violating the consumers' trust, might want to activate a clause in the contract that allows him to reduce the resources provided to some consumers (e.g. number of VMs) offering monetary discounts to compensate this reduction. Unfortunately, none of the existing SLA definition languages offers this possibility. Two solutions are commonly employed to mitigate this problem.

In the first, only a generic specification of the service and its quality is defined. Providers specify generic terms, such as service availability, or even service classes, such as Silver and Gold, under which new instances are created. However, this approach provides only a high-level account of the service, which may be a source of ambiguity for the verification of the service quality. Moreover, the addition of resources or changes in the provided service are subject to the prices and availability at the moment of the request, which may vary considerable since the original agreement does not impose them any restriction.

The second approach to mitigate the dynamicity problem in clouds is the renegotiation of the SLA. However, automatic (re)negotiation of SLAs is complex and time consuming [START_REF] Pichot | Towards dynamic service level agreement negotiation: an approach based on WS-Agreement[END_REF][START_REF] Shen | Adaptive negotiation for agent-based grid computing[END_REF][START_REF] Green | Service level negotiation in a heterogeneous telecommunication environment[END_REF][START_REF] Lee | A design space for dynamic service level agreements in OpenStack[END_REF]; it entails the costs of formulating, taking decision and analysing the proposed SLA modifications [START_REF] Lee | A design space for dynamic service level agreements in OpenStack[END_REF]. It does not offer the flexibility of acting/planning without the authorisation of the other parties, and does not guarantee elasticity to the service because requests can always be refused. Furthermore, renegotiation cannot replace contracts specified in natural language because they may include conditional clauses which trigger automatic changes.

To overcome the lack of support for dynamic changes in the SLA definition languages we introduce a conceptual framework, devised for the cloud domain, that enables the specification of conditions and events in which changes (due to, e.g., violations or requests from parties are permitted in the SLA. We propose two mechanisms to perform changes in the SLA. The first mechanism allows unilateral changes, where the authorisation by the involved parties is not necessary if the conditions defined in the SLA are satisfied. The second mechanism enables changes only with the explicit authorisation of the involved parties. Differently from the renegotiation approach, in this case, the modifications are defined in the contract, which allows the parties to predict possible changes and speed up the decision-making process. We implement this framework as an extension of SLAC [START_REF] Uriarte | SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF], a SLA definition language for clouds which, as the other existing definition languages, did not include mechanisms to support dynamic SLAs.

The main contributions of this paper are: (i) an innovative approach to capture the dynamism of clouds in the SLAs through the definition of cases in which the terms of the SLA can be changed; (ii) a formal extension of the SLAC language to support dynamic SLAs, and (iii) the implementation and comparison of our approach against the traditional SLA renegotiation. Before presenting the extension of SLAC to support dynamism (Section 2), some experiments (Section 3) and the impact of dynamic SLAs in different fields (Section 4), we briefly discuss the related works.

A generic SLA framework that supports the reservation of long term capacity at pre-specified prices is proposed in [START_REF] Garg | A SLA framework for QoS provisioning and dynamic capacity allocation[END_REF]. The focus is on the service admission control from the provider side and on providing solutions for capacity allocation in scenarios in which consumers reserve resources for fixed prices. This approach is problem specific and the authors clarify that the work is a pragmatic first step towards more dynamic pricing scenarios. Neither the framework, nor the SLA definition language to support this feature, nor the mechanism to reserve the resources are discussed. Similarly, other works provide solutions considering implicit changes in the services quality level, but, to the best of our knowledge, none of them defines a conceptual framework with an actual implementation or studies the contractual nature of such changes and its implications in the SLA.

An interesting discussion on the management perspective of dynamic SLAs is reported in [START_REF] Lee | A design space for dynamic service level agreements in OpenStack[END_REF], it is stressed that, due to rapidly changing requirements of consumers and providers, clouds require dynamic SLAs. Also possible design choices for such systems are surveyed and the main phases of SLA management, such as admission control, monitoring, SLA evaluation and enforcement are clearly introduced. The focus, however, is on the discussion of the requirements of management systems, in particular of Openstack, to provide this flexibility in clouds and the issues of creating dynamic SLAs for clouds are not addressed.

The WS agreement language is extended in [START_REF] Di Modica | Dynamic SLAs management in service oriented environments[END_REF][START_REF] Di Modica | Dynamic re-negotiations of SLA in service composition scenarios[END_REF] to support modifications at run time using renegotiation; this involves a party requesting the desired modification and the other one accepting it. An on-line renegotiation extension for WS-Agreement is instead proposed in [START_REF] Djemame | Enabling service-level agreement renegotiation through extending WS-Agreement specification[END_REF]; renegotiation templates are introduced which specify the terms that can be modified during the renegotiation (dynamic or static Service-Level-Objectives). Similarly, many other works propose renegotiation of SLAs (e.g. [START_REF] Galati | Designing an SLA Protocol with Renegotiation to Maximize Revenues for the CMAC Platform[END_REF][START_REF] Parkin | An SLA re-negotiation protocol[END_REF][START_REF] Omezzine | Towards a dynamic multi-level negotiation framework in Cloud computing[END_REF]). However, they are not suitable for the cloud domain since they do not enable the specification of changes in the agreement without a negotiation process, which involves requests, proposals and decision-making from the involved parties.

Supporting Dynamism in SLAC

The requirements of the parties involved in the service provision in clouds change rapidly. This changes are not limited to elasticity but can range from business aspects, e.g., expiration date and payment model, to the quality-of-service, e.g. response time. However, SLAs are commonly non-modifiable documents, unless a renegotiation process is carried out and the involved parties agree on new terms. Aiming to reflect the dynamism of clouds into SLAs without the weight of a renegotiation process, we have developed a mechanism to enable changes in SLAs inspired by contracts specified in natural language. The intuition behind this mechanism is the specification in the contract itself of the conditions and the terms which can be changed.

We designed an extension of SLAC [START_REF] Uriarte | SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF], named dSLAC, to support this mechanism and enable parties to modify the terms during the service provision. The SLA itself contains the specification of the conditions and terms which can be modified and is divided into two sections: the Dynamism, where the triggers for changes, the conditions and the modifications are specified; and the Invariants, which defines fix boundaries for the SLA terms.

Event ::= violation

Table 1: Syntax of the SLAC language (an excerpt from [START_REF] Uriarte | SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF]).

Syntax

SLAC is a language for the specification of SLA for clouds, which focusses on: (i) formal aspects of SLAs; (ii) supporting multi-party agreements; (iii) business and utility aspects; and (iv) proactive management of the agreement as well as the cloud system. For the sake of readability and self-containedness, we report in Table 1 (an excerpt of) the syntax of the the SLAC core language (the complete syntax of SLAC and its extensions can be found in the project's web page [START_REF]SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF]). The syntax is formally defined in the Extended Backus Naur Form (EBNF), in which italic denotes non-terminal symbols, while teletype denote terminal ones.

The description of a SLA comprises a unique identification code (Id ) and at least two involved parties. The terms of the agreement express the characteristics of the service together with their respective expected values. Each SLA requires the definition of at least one term, which can be either a Metric or a Group of terms (which enables the re-use of the same terms in different contexts). Each term defines the party responsible to fulfil the term (a single party) and the contractors of the service (one or more). SLAC supports different metrics, e.g. the NumericMetric, which is constrained by open or closed Intervals of values and a particular Unit. The specification of intervals in numeric metrics relies on the evaluation of expressions (Expr ). Finally, Guarantees ensure that the terms of the agreement will be enforced or, in case of a violation Event, define the actions that will be taken.

The syntax of dSLAC is obtained by extending that of SLA and is presented in Table 2. The symbol ::= is used when a new rule is added to the syntax, while + = is used to extend an existing syntactic rule.

The dynamic changes cover two sections of the SLA: Dynamism and Invariants. The former specifies events, conditions and changes, whilst the latter provides fixed rules that regulate these changes, i.e. the modification of the agreements specified in the Dynamism section are only performed when they are compliant with the conditions defined in the Invariants section. Although the invariants could be specified as conditions in the Dynamism part of the agreement, we opted to specify them as separated sections to have clearer specification and semantics.

The changes in the Dynamism section are based on Events, such as requests from parties or SLA violations. Then, one or more conditions can be defined (ConditionModification), which can be an expression Expr, as defined in the core language, or express the need of the authorisation from one or more parties.

Afterwards, the modification are specified using three actions: add term, delete term and replace value. The add term operation inserts a new term, which is not specified in the initial SLA. It requires a Term, which includes the involved parties, metric and value. The delete term removes a SLA term, which requires only the reference to an existing term (RefTerm). The replace value operation substitutes the value of an existing term with a new value (MetricValue), which can be, according to the metric type, an Interval and its Unit, a Boolean or a set of lists. Replacements can use reserved variable names, which refer to, e.g. the current values of the existing term, of another term or the number of times the SLA was violated. In case of multiple terms using the same metric (e.g. in different groups) the reference to the metric must be complete, including involved parties and groups, to avoid ambiguity.

Finally, the Invariants section defines rules that cannot be changed by dynamic actions, i.e. fix bounds for terms of the contract. They can define, for example, that a user cannot request more than 1000 Virtual Machines (VMs) and never less than 1 or that the provider must always backup the data of the consumer. Events that trigger changes in the contract will not be applied unless they are compliant with the terms defined in this section. 4.

Semantics

The semantics of a SLA specified via SLAC is formulated as a Constraint Satisfaction Problem (CSP) that verifies: (i) at negotiation-time, whether the terms composing the agreement are consistent; and (ii) at enforcement-time, whether the characteristics of the service are within the specified values.

In the formal SLAC semantics ( [START_REF] Uriarte | SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF]) a SLA was given by means of a function SLA that returned a pair composed of a set of group definitions and a constraint representing the semantics of SLA's terms. This pair constituted the CSP associated to the agreement; details can be found in [START_REF] Uriarte | SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF].

In dSLAC the possibility of changing the set of valid constraints calls for a different approach. The agreement is represented by an automaton in which each state is labelled by a set of constraints and each transition by the event that modifies the constraints. The initial state of the automaton is created using the original semantics of a SLA, which converts the agreement without the Dynamism and Invariants sections into a CSP. Then, all possible new states are created considering events, conditions and the triggered changes to the SLA constraints specified in the Dynamism section, as well as the invariants of the agreement, which are defined as additional conditions to every transition of the automaton.

Figure 1 illustrates this approach based on the second example of dynamic SLA, discussed in the next section and presented in Table 4. For the sake of simplicity, the automaton does not include the dynamic part that requires authorisation from the consumer. In this case, the consumer can request 2 additional VMs when the SLA state is the initial one (corresponding to the service quality level Base and passing to state Gold) and remove 2 of them when the total number of VMs is 4 (from state Gold back to sate Base). Also, the provider can request an increase in the Response Time in state Gold compensating the consumer with a reduction in the price (passing to the state Silver). Even if in the state Silver, the consumer can reduce the number of VMs to 2 and return to state Base.

Examples

We illustrate the dynamism of SLAs using two examples. The first is presented in Table 3; it is an instance of an Infrastructure-as-a-Service SLA from a provider named IMT which initially delivers 2 VM to consumer Rafael. In this scenario, the consumer adds and removes VMs according to his needs, if the number of VMs does not exceed 200. The #1 represents the current value of the lower bound of the interval of the term and #2 the upper bound.

In the second example, presented in Table 4, we use the same scenario and base SLA as the first example, modifying only the Dynamism and Invariant parts. In this case, the consumer adds and removes VMs for a fixed price but must respect the limits defined in the Invariants, that is, in this case, he can have only 2 or 4 VMs at the same time. The provider may request an increase in the response time if the number of VMs is equal to 4. If so, as a compensation to the consumer, the price is then reduced by 50 cents. Moreover, on provider's request, a consumer may accept an increase in the response time of 5 ms, for a reduction of 10 cents in the price, always considering the ranges defined in the Invariants section that, in this example, limits the response time between 0 and 35 ms.

Experiments

To illustrate the SLAC extension and the benefits of dynamic SLAs we present a case study in a cloud testbed for the execution of cloud services and simulates the interaction between a provider and multiple consumers.

For the sake of simplicity, apart from the Dynamism and Invariant sections, the SLAs have only: the definition of the service execution deadline, the price to execute the service and the penalty in case of violation of the deadline. We compare three different approaches: Static SLAs, in which SLAs do not change during their lifetime; Renegotiation, in which the parties can renegotiate the existing SLA; and our approach, Dynamic SLAs, which enables the definition of modifications in the agreements. For this comparison, we analyse the number of violations, penalty and the total revenue of the provider.

The need for dynamism in this use case is demonstrated in three cases:

-Request for modification from the consumers, commonly caused by change of requirements, which we simulated by randomly selecting services in execution; -High violation risk, which is detected during the service execution to enables the provider to change the agreement and avoid violations; -Low violation risk, which is also detected during the service execution and enables the provider to increase its revenue, for example increasing the price but reducing the deadline of the service.

The results demonstrate the flexibility dSLAC and its capacity to reduce the number of SLA violations and to improve the revenue of the involved parties.

Use Case Model

The framework developed for the coordination of the execution of services has several components, as depicted in Figure 2. The SLAC Framework parses and evaluates SLAs, which contain the service specification and requirements, and sends this description to the Service Execution Framework. This latter component Fig. 2: Components of the use case framework.

is specifically designed to guarantee the correct deployment and execution of services and to manage the cloud infrastructure and employes schedules services using the approach presented in [START_REF] Uriarte | Service Clustering for Autonomic Clouds Using Random Forest[END_REF]. The Panoptes Monitoring System [START_REF] Uriarte | Panoptes: A monitoring architecture and framework for supporting autonomic Clouds[END_REF] provides the status of the system and services to the Violation Risk Analyser and to the SLAC Framework and is directly configured by the Service Execution Framework. The Violation Risk Analyser measures the risk of the running services of not meeting the deadline specified in the SLA and updates the Renegotiation Decision System. Finally, the Renegotiation Decision System creates proposals of modifications for the SLA and decides, when using the Renegotiation approach, whether to accept changes in the services. The violation risk analysis is performed using Supervised Random Forest [START_REF] Breiman | Random forests[END_REF], a machine learning technique, and is based on the monitoring information of services and the SLA itself.

The algorithm defined for the experiments is used for each service regardless the evaluated approaches and is depicted in Figure 3. Each service is evaluated only once during its execution lifetime, in time t r , which is a random point between the initial time and the deadline of the service defined in the SLA. In the case of Static SLAs, the services are computed employing the SLA defined at design time and, when the service ends or the deadline is achieved, the system verifies whether the SLA was violated and then assesses the price paid and the possible penalties. In the Renegotiation approach, first the violation risk is measured. If it is not higher or lower than a specific value, the system verifies whether the service was randomly chosen. If not, the service is computed normally with the SLA defined at design time. Renegotiation take place in case of high violation risk to avoid penalties and customer insatisfaction; in case of the payment of low violation risk, to raise provider revenues by, e.g. shortening the deadline; and to simulate changes of requirements from consumers when the service was randomly chosen. A party sends a SLA proposal to the other party that analyses it according to its priorities using a Fuzzy Decision System, as described in the next section. If the new agreement is accepted, the service continues and is evaluated considering the new SLA, otherwise the initially defined agreement is the valid one till the end of the service.

In this use case, compared to Renegotiation, the only difference of the Dynamic approach is that the renegotiation and consentment of the involved parties is not necessary, that is, in case of low violation risk or high violation risk or the service being randomly chosen, the agreement is modified automatically since the changes are pre-defined in the SLA. In both cases a bonus is given to the other when a change is made during the service execution in order to motivate or compensate the other party for the changes. Although the bonus a priori is usually much smaller than the bonus required for renegotiating the SLA during the execution, for the sake of simplicity, we opt to use the same range of values of the Renegotiation approach.

Fuzzy Decision System

The Renegotiation approach requires the analysis of the difference between the initial agreement (pre-runtime) and the SLA proposed for renegotiation, and the assessment of the benefits before deciding whether accept or refuse a new agreement. In our use case, to simulate this process that is typically carried out by a human being or autonomous decision systems, we designed a fuzzy logic decision support system inspired by the approach presented in [START_REF] Djemame | Enabling service-level agreement renegotiation through extending WS-Agreement specification[END_REF].

Our decision system takes as input the rate (positive or negative) of change for the considered parameter; for example, if in the renegotiation process the provider requests and increases of 20% on the price, one of the parameters is 20. With these inputs, the system decides whether the new SLA is beneficial, neutral or not beneficial to the party. In the case of consumers, the system also takes Table 5: Fuzzy rules of the provider decision system.

into account the priorities of each consumer, for example, if the deadline is the priority of consumer 1 the influence of this variable is highlighted in the decision. Fuzzy rules interpret the relationships between the inputs and outputs and are constructed in the logical form. In the use case, the inputs are: the deadline for the service (D), the price to be paid for the service (P r ) and the penalty in case of violation (P e ). Table 5 exemplifies some rules exploited in the use case and applied by the provider's fuzzy decision system. Despite being fixed for the provider, the rules change according to the priorities of each consumer. For a complete account of the fuzzy rules and the framework used in the experiments, we refer to the website of the SLAC project [START_REF]SLAC: A Formal Service-Level-Agreement Language for Cloud Computing[END_REF].

Evaluation

The experiments were conducted in a cloud with 2 physical machines, providing 12 heterogeneous VMs, in which the agents are employed to execute services.

In the experiments, services are generated based on the distribution of a trace of real-world cloud environment, the Google's cloud dataset [START_REF] Reiss | {Google} cluster-usage traces: format + schema[END_REF], and the same services are executed using all three described approaches. Each service has an associated SLAC SLA, which is created along with the service, according to an estimation of the resources necessary to finish the service within the completion time. The features are: CPU, RAM, Requirements, Disk Space, Completion Time and Network Bandwidth. Different types of services are used in the experiments, such as web crawling, word count, machine learning algorithms, number generation and format conversion, which are close to real-world applications [START_REF] Nanduri | Job Aware Scheduling Algorithm for MapReduce Framework[END_REF]. Service's penalty and price are generated along with the SLA and are based on the service execution time and a randomly defined number. Penalties are always higher than the price, since the price is paid even if a service is violated.

The training set for the SLA Risk assessment is built in every round of experiments by executing 1000 services. Then, it is used to train the machine learning algorithm to provide the probability of classifying a new service into the violated and not violated classes.

In each round of experiments, new services are generated (for creating the training set and for testing the approaches) and the same services are executed for all approaches. The number of services ranges from 100 to 500 (with 50 services interval). We assume that the services' arrival is a Poisson process, i.e. the time between consecutive arrivals has an exponential distribution and, in our case, a service arrives in average every 0.7 seconds. The Fuzzy decision system accepts proposals which are beneficial to the requested party. Therefore, the requester and the Renegotiation Decision System usually offer compensations for the requested party that fulfil the need of the requester, e.g. if the violation risk is high, the provider requests more time to finish the service but offers it with a discount on the price and higher penalty.

The definition of the exact parameters of the considered metrics of the SLA modification proposal, which are used by Renegotiation and Dynamic approaches (though the latter applies changes without requesting the approval of the other party), are randomly generated in a predefined range. The results of these experiments are illustrated in Figure 4 considering different number of services. Table 6 presents the overall results, relative to the Renegotiation and Dynamic approaches, expressed as percentages: in the case of Penalties and Revenue characteristics, the results correspond to a comparison with the Static approach, whilst in the case of the other measured characteristics they result from a comparison with the total number of services. Considering the parameters defined for the Renegotiation approach and the benefit threshold used in the experiments, around 60% of the Modification Requests were accepted and carried out. Using the Dynamic approach, 21% of the services were Modified mainly due to High Risk of violation (more than 19 %). The total number of Modifications is relatively high due to the accuracy of the machining learning algorithm, in which we prioritised the identification of high-risk SLAs. Consequently, the number of false positives increased, i.e. some SLAs that normally would not be classified as high-risk, in this case, were considered high-risk. In the Renegotiation and Dynamic approaches, 14% and 19% of the SLAs classified as high-risk and more than 10 % of the Randomly selected were violated. Overall, the flexibility provided by the Dynamic approach increased the Revenue by 22% and reduced the Penalties by 64%, whilst these measures were only 13% and 31% for the Renegotiation approach.

Discussion

In the experiments, the use of the renegotiation and the dynamic mechanisms of SLAs heavily depend on the accuracy of the violation risk analyses approach. The results show that, although the penalties were reduced by 64%, the impact on the total revenue was an increase of around 22%. The main reasons for this difference are: the limited impact of the penalties on the total revenue due to the average number of violations; the compensation provided to the consumers when a modification is requested, which lowers the price paid for that service and sets higher penalties in case of violation; and the number of modified SLAs which were violated since most of the modification requests increase the penalty as a compensation to increasing the service completion time, which suggests that performing an analysis to define the additional time required to avoid violations instead of generating a random number could improve the total revenue. The experiments were focused on avoiding SLA violations, and in few opportunities the Dynamic and Renegotiation mechanisms were used to improve the revenue of the parties (only around 1.4% of the services were considered low-risk or randomly selected). In most scenarios, these mechanisms can be more aggressively employed to improve the revenue, mainly when a better accuracy is reached by the risk analysis.

Also, the parameters defined in the SLA modification proposal may have a considerable impact on the results. We adjusted these parameters to simulate a real-world situation, where every party defends his interest.

Finally, the results demonstrate that dSLAC provides flexibility for the parties and significantly improves the optimisation of the SLA management. Moreover, it can always be used together with the renegotiation approach in case not all relevant modifications are included in the SLA.

Conclusions and future works

To address the lack of support for the cloud dynamism in the existing SLA definition languages we have introduced a new approach for the specification of dynamic SLAs for clouds. This dynamism is achieved through the specifications, in the SLA itself, of the conditions and of the modifications that will be applied to the SLA once the related conditions are met. We have introduced syntax and semantics of an extension of the SLAC language and described its implementation and possible usage. We have provided evidence of the advantages of our approach in comparison to static SLAs and the use of renegotiation.

Since our approach is devised also for business, it may be used to back-up legal disputes. In fact, in designing dSLAC, we took the legal aspects of contract formation into account. Our approach is compliant with the norms defined in [START_REF] Parkin | Challenges in EU Grid Contracts[END_REF], where the authors discuss the provision of services from the legal standpoint using the European Union directives for E-Commerce as reference. Thus, dynamic SLAs, i.e. SLAs with pre-defined changes based on events and conditions, can be used in legally binding contracts. We conclude by discussing the impact of dynamic SLAs in the cloud domain and the related challenges that we plan to address as future work. Indeed, this approach impacts in areas related to the creation and management of services and poses new important challenges in the field while looking at them from different perspectives.

The negotiation process needs considerable changes to support this feature. The first challenge is the matching of offers and requests of services since the possible changes must be considered. This matching mechanism needs to verify whether the requirements of the parties comply with all possible states of the SLA, taking into account the conditions for such changes. Depending on the changes defined on the SLA, a large number of states need to be analysed, which is a computation intensive process, and new techniques are needed to address possible problems, such as explosion of states. Moreover, crisp solutions that simply verify whether there exist a single state that is not compatible with the specification of the parties may imply low matching rates, whilst an algorithm considering the probability of reaching a non-desired state could improve this rate. Considering the complexity of this process, the negotiation can hardly be performed by humans and new algorithms, for example, based on model checking, that take into account the priorities of the involved parties should be develop to define SLA proposals and to assess their benefits.

The scheduling, service admission and resource reservation areas also need to consider the possible changes in the services. As the modifications in the agreement do not need the authorisation from the provider, the consumer can request changes in unexpected times and the provider must cope with them. Although most of the existing methodologies already employ statistical methods to predict the load of the system, the agreement with pre-defined changes is valuable source of knowledge as it contains the explicit definitions of the changes which are more likely to happen or that are expected by the parties. Moreover, the methodologies can also use the conditions pre-defined in the SLAs to adjust the load of the system. This process is complex and requires multi-objective solutions to find the optimal (or a better) scenarios for such cases since the possibilities in large scale are numerous. For example, even if a consumer requests a large number of new VMs, the provider can avoid violations of SLAs by removing VMs from other consumers, by e.g. providing a discount to them.

Service and infrastructure Monitoring are essential for the decision-making and SLA management. With dynamic SLAs, this process needs to adapt the knowledge generation methods to use the collected data before and after the changes. Finally, management systems must track the changes in the SLA for billing purposes and for legal reasons (e.g. in case of disputes).

  SLA ::= id: Id parties: PartyDef PartyDef + term groups: Group * terms: T erm + guarantees: Guarantee * Group ::= GroupN ame : T erm + Term ::= P arty -> Party + : Metric | [Expr,Expr] of GroupN ame Party ::= Role | P artyN ame Metric ::= N umericM etric not ? in Interval U nit | . . . NumericMetric ::= cCPU | RT delay | response time | RAM | price | . . . Interval ::= ]Expr, Expr[ | ]Expr, Expr] | [Expr, Expr[ | [Expr, Expr] Unit ::= GB | # | ms | EUR/Hour | . . .

  SLA += Dynamism: Dynamism * Invariants: M etric * Dynamism += on Event : ConditionModification ConditionModification ::= (if ExprModification then Modifications) + (else Modifications) ? | Modifications ExprModification ::= Expr | P arty authorises Modifications ::= Modification and Modifications | Modification or Modifications | Modification Modification ::= add term T erm | delete term Ref T erm | replace value of Ref T erm with MetricValue RefTerm ::= (P arty => P arty + :) ? (GroupN ame:) * ComposedM etric ComposedMetric ::= N umericM etric | ListM etric | BooleanM etric | GroupN ame MetricValue ::= Interval U nit | Boolean | {ListElement + } or {ListElement + } * Event += P arty request | SLA expiration | . . .

Fig. 1 :

 1 Fig. 1: Automaton of an excerpt of the example in Table4.

Fig. 3 :

 3 Fig. 3: Flow diagram of the tested approaches: Static, Renegotiation and Dynamic.

  Pr or D increases beneficial If Pr and D increase very beneficial If Pe increase < 10% neutral

Fig. 4 :

 4 Fig. 4: Performance analysis

Table 2 :

 2 Syntax of the dSLAC language.

Table 3 :

 3 IaaS Example: consumer can add and remove any type of VM up to 200 VMs.

	SLA
	...
	Term Groups:
	Small VM:
	Imt → Rafael:cCpu in [1,1] #
	Imt → Rafael:RAM in [4,4] GB
	Imt → Rafael:RT delay in [0,10] ms
	Imt → Rafael:price in [0.22,0.22] EUR/Hour
	Terms:
	[2,2] of Small VM
	Dynamism:
	on consumer request:
	replace value of Small VM with [#1+1, #2+1] or
	replace value of Small VM with [#1-1, #2-1]
	Invariants:
	Small VM in [0,200]

Table 4 :

 4 Example of a more complex dynamic SLA.

	SLA
	...
	Dynamism:
	on consumer request:
	if Small VM == 2
	replace value of Small VM with [#1+2,#2+2] and
	replace value of Price with [#1+2.4,#2+2.4]
	on consumer request:
	replace value of Small VM with [#1-2,#2-2] and
	replace value of Price with [2.0, 2.0]
	on providers request:
	if Small VM == 4 and RT delay == [0,20]:
	replace value of RT delay with [0,30] and
	replace value of Price with [#1-0.5,#2-0.5]
	on providers request:
	if consumer authorises:
	replace value of RT delay with [0,#2+5] and
	replace value of Price with [#1-0.1,#2-0.1]
	Invariants:
	RT delay in [0,35]
	Small VM in [2,4]

Table 6 :

 6 Experimental results


Paolo Bottoni
email: bottoni@di.uniroma1.it

Emanuele Gabrielli
email: gabrielli@di.uniroma1.it

Gabriele Gualandi
email: gualandi@di.uniroma1.it

Vincenzo Luigi

Franco Mancini
email: mancini@di.uniroma1.it

Stolfi
email: stolfi@di.uniroma1.it

FedUp! Cloud Federation as a Service

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In the last few years, cloud-based solutions have become of interest for public and private organizations, due to the possibilities they offer for achieving: [START_REF] Stolfi | The rise of RaaS: the resource-as-a-service cloud[END_REF] greater cost reductions, by moving part of the budget from fixed to variable costs; and (2) greater resilience, and by increasing the flexibility and scalability of resources in response to changing business needs. Nevertheless, some elements -such as customers' perception that they are losing control over infrastructure resources, or the risk of vendor lock-in, stemming from a pervasive use of provider's services-are still an obstacle to the use of cloud solutions.

In order to mitigate these problems, many organizations are trying other cloud computing strategies including the creation of federations of individual clouds, from which they expect optimization of workload, increased availability of resources, probably even at more competitive costs and on an as-needed basis, and high levels of security and quality of service, probably better calibrated on the needs of an individual cloud joining a federation [START_REF] Kertesz | Characterizing cloud federation approaches[END_REF].

Current approaches to the construction of federations of clouds, see e.g. Fogbow1 , Zentera2 , Reservoir [START_REF] Rochwerger | The Reservoir model and architecture for open federated cloud computing[END_REF], handle federation services through some specific applications or frameworks. Hence, specific components must be installed on the infrastructure of the federation members, which are required to provide a certain amount of resources to run these components. In addition, when federating heterogeneous individual clouds, one has to consider the presence of: (1) distinct domains; (2) different security policies and service levels; and (3) different repositories of accounts. Other issues include the technological compatibility between the framework and the infrastructure of the individual member clouds, which may require adaptation to join a federation. All of this brings increased time and cost, which could make joining a federation inconvenient or impossible.

Faced to these problems, we argue that construction and management of federations of individual clouds should be seen as cloud services in turn, thus allowing a drastic simplification in the federation set-up process, the decoupling of the federation management services from the technologies adopted by the individual clouds, and minimal technological complexity and intrusiveness in the individual cloud infrastructures, while increasing the flexibility and scalability of resources. A further advantage is that joining a federation and contributing or obtaining resources to and from a federation could be achieved at a fine grain directly by end-users or with reduced intervention of cloud administrators.

In this paper we outline the basic requirements and the available technologies -in particular containers, configurators and orchestrators-which allow us to introduce the FedUp! approach to lean deployment and management of federations of heterogeneous clouds, by devising some simple mechanisms for setting up a federation and for allowing individual clouds to join an existing federation.

Paper organisation. After concluding the introduction with a brief overview of related work, Section 2 presents the requirements and features on which the approach is based. Section 3 discusses the organisation of the FedUp! platform as a collection of microservices, possibly allowing a same cloud to join different federations, or even to participate in one federation in multiple ways, with different levels of service, Section 4 provides a description of how the approach can be realised with current technologies. The interactions involved in the execution of the main services for creating and managing federations of clouds are described in Section 5. Finally, Section 6 provides conclusions and points to future work.

Related Work

A layered model was proposed for the management of applications in a federated cloud in [START_REF] Villegas | Cloud federation in a layered service model[END_REF], where communication among clouds in the federation occurs at the respective layers (SaaS, PaaS, and IaaS 3 ). In their proposal, a service request to a cloud, for an application at the SaaS level, will traverse layers and contact brokers at the different layers as needed, but the model does not consider the offering of specific services at federation level.

Reference to the cloud layers is made in [START_REF] Bermbach | Cloud federation: Effects of federated compute resources on quality of service and cost[END_REF] to introduce a distinction between horizontal (same layer) and vertical (across layers) federations, focusing on horizontal ones, where two fundamental scenarios are considered, viz. redundant deployment of services and service migration from a cloud provider to another, the service becoming accessible through a different endpoint. They provide a reference architecture describing services to be offered by a federation, but do not discuss dynamic creation and join/leave on the individual cloud side When considering federations of heterogeneous clouds with some common level of trust, the notion of community cloud arises, as proposed in [START_REF] Marinos | Community cloud computing[END_REF] and elaborated on from the point of view of security in [START_REF] Nicanfar | Community cloud: Concept, model, attacks and solution[END_REF]. Here, each node in the participating clouds can play both the roles of producer and consumer, and a specific layer for coordination is proposed, including management of virtual machines, identity, networking, and transactions.

The kind of flexibility and the fine granularity that the FedUp! approach grants is also in the direction of Resources as a Service, as advocated at the cloud level in [START_REF] Stolfi | The rise of RaaS: the resource-as-a-service cloud[END_REF], where users could subscribe to the usage of resources maintained by a cloud for as much as needed, instead of declaring beforehand the amount of resources they expect to need. By making joining and leaving federations easy, shorter turnaround times can be achieved, thus enabling greater responsiveness by federations to the requests coming from individual clouds.

FedUp! Overview and Requirements

We are developing the FedUp! approach (and the homonymous platform) to setting up and managing federations of resources from individual clouds in a simple and non-intrusive way, based on cloud services, i.e. services (e.g. Paas, SaaS, and IaaS) made available to users on demand via the Internet and fully managed by a provider. In particular, FedUp! has been designed as a platform by which to create federations in a PaaS style, based on the following activities.

1. Manage the entire life cycle for a federation (creation, management of individual cloud membership, management of feature descriptions and of featurebased bidding and awarding of membership, dismissal). This will in turn exploit mechanisms based on cloud services, setting the basis for the new notion of Federation as a Service, thus enabling fastest federation startup time, decoupling of services from technologies for service distribution, smaller intrusion in the technological choices for member clouds (though not completely technology-agnostic, the approach can be targeted to various implementations), greater flexibility in management of single federations. 2. Allow a cloud to: (1) become a member of several federations at a time (through multi-tenancy); (2) apply for becoming a member of any federation based on a description of the resources it can contribute and/or of the resources it needs to acquire; (3) easily migrate from one federation to another. This will grant ample possibilities to individual clouds for choosing the federation to join, greater flexibility in managing the membership agreement, and a better appreciation of its resources. 3. Maintain a central repository storing the records concerning the generated federations. Each federation is described by a set of features (publicly represented in the form of tags). This will allow the generation of theme-based federations offering a set of specific services to the member clouds.

We state a list of requirements for lean mechanisms for establishing, managing and granting access to federated clouds, classified under three categories: General (GR) Overall view of the system Federation (FR) Resource-sharing and management of the federation. Usability (UR) Point of view of the user of the framework, either as administrator or as end-user.

Table 1 expresses the identified requirements for the two basic mechanisms of generating and of managing a federation with FedUp!.

Table 1. General requirements for generating and managing federations GR1 FedUp! must support heterogeneous clouds. GR2 FedUp! must have low impact on the existing infrastructure of individual clouds. GR3 FedUp! must allow the generation and dismissal of federations in a transparent way with respect to individual clouds. FR1 FedUp! must support the join of new member clouds and their abandoning. FR2 FedUp! must support an automatic generation of federations. FR3 FedUp! must generate federations orchestrated by an automatic system. UR1 FedUp! must provide the generated federation with mechanisms to allow access control to federation resources. UR2 FedUp! must allow a generated federation owner to specify the values of a pre-defined set of tags.

Table 2. Specific features required on a microservice implementation

F1

In order to be realistically orchestrable, microservices must work in isolation without requiring a dedicated VM each.

F2

In order to be efficiently orchestrable (e.g. to support redundancy or migration), microservices have to be properly defined, by separating different data domains into different services, as expected in a microservice scenario.

Generating and Managing Federations with FedUp!

In this section we describe the main components and functionalities of the FedUp! platform and the naming conventions used in this paper.

FedUp! is an innovative solution for generating and managing multiple cloud federations using an approach based on cloud services. A federation is conceived as a set of contributions from individual clouds with the aim of sharing and optimizing their own resources, together with a number of services for the dynamic proposal, acquisition and withdrawal of these contributions.

We refer to any federation generated via the FedUp! platform as a Federation. The owner of the individual cloud or tenant starting the generation process for a Federation, is referred to the Federation owner.

The actors which may interact with the platform have been identified as:

-FedUp! Administrator, responsible for FedUp! platform management.

-Cloud or tenant administrator, using the FedUp! utilities to create a Federation, or to make an individual cloud (or tenant) join an existing Federation generated with FedUp!. -User of a cloud member of a Federation, who can request resources or services made available to the Federation. To integrate a cloud that wants to adhere to a Federation.

FedUp.Fed.Search

To search for active Federations that satisfy the requirements of an individual cloud. This option is available for clouds that are looking for Federations to adhere to.

FedUp.Cloud

Services for cloud/tenant management.

FedUp.Cloud.Join

To adhere to a named Federation or to Federations characterized by given tags. FedUp.Cloud.Join(target) To adhere to a targeted Federation.

FedUp.Cloud.Join(tags[])

To adhere to a Federation that matches the given requirements (tags).

FedUp.Cloud.Update

To change/update a cloud features, tags included.

FedUp.Cloud.Leave

To allow a cloud to leave a Federation, releasing the resources that cloud allocated to that Federation.

FedUp.Cloud.Search

To search for available clouds matching the requirements of a Federation that wants to acquire clouds.

As FedUp! is based on cloud services, in order to avoid ambiguities, we call "Utilities" the services that manage FedUp!. Each utility consists of a set of operations named "Actions" (see Table 3). FedUp! presents two main utilities:

-FedUp.Fed: this utility supports the generation and management of the Federations created with the FedUp! platform. Each Federation can consist of the aggregation of specific features established by the Federation owner at creation time (e.g. based on requested or granted quality of service, the level of safety on economic factors of political, institutional, geographical, etc.). The Federation features are described as tags. A dictionary of accepted tags is defined by FedUp! and the owner can choose the tags with their associated values, characterizing the new Federation at creation time. Tags are used by search functions available for the individual clouds to select the federations that match the membership requirements. -FedUp.Cloud: this utility supports the communication with individual clouds requesting to join a Federation. Each individual cloud can join a specific Federation or can apply to join any Federation that matches specific tags.

These utilities rely in turn on the following structures:

- The information provided by FedUp.ServiceRegistry fully defines a Federation infrastructure service, in terms of the information necessary to a cluster manager to correctly deploy and maintain the service. In particular, the following queries are handled:

given the id of a service, the id s of the microservices composing that service; given the id of a microservice, the id of a container image relative to that microservice.

Finally, FedUp.ContainerHub can be queried to retrieve, given the id of a microservice, the correspondent image of a container.

An overview of the proposed solution is drawn in Figure 1, while more information about how its realization is given in Section 4.

Implementation Aspects

In this section we provide some information about how to define a service configuration for a Federation and how to deploy the corresponding set of microservices using containers based on Docker4 , Saltstack5 and Kubernetes6 technologies.

We briefly introduce the following notions.

-Microservice: a term referring to a way of designing an architecture as a set of independently deployable services [START_REF] Newman | Building Microservices. Designing Fine-Grained Systems[END_REF]. A single service can be thought as composed of a set of loosely-coupled microservices.

-Configuration Management Engine: a software responsible of ensuring that a remote Operating System is properly configured in terms of the presence of files, installed packages and running services. -Container : an isolated, resource-controlled, portable operating environment.

-Container Cluster Manager : a software capable of orchestrating Containers among a set of nodes, managing a so called Container Cluster.

SaltStack is a well-known Configuration Management Engine based on a master-slave architecture [START_REF] Sebenik | Salt Essentials. Fast, Scalable, and Flexible Automation[END_REF]. It is also classifiable as a Remote Execution Engine since it allows the execution of remote executable files. The SaltStack master configures the Operative Systems of a set of machines (called minions) such that they comply with certain desired states. Among other configuration management engines, Saltstack is characterized by the use of asynchronous message queues. Containers are widely used to deploy software, since they are a more efficient alternative to virtual machines.

Docker is a common implementation of containers. Kubernetes is a Container Cluster Manager based on a master-slave architecture. It is defined as a system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. Kubernetes automatically manages a cluster of containers by means of a scheduler, changing the state of the cluster to keep it consistent with respect to a set of declarative primitives, codified as YAML 7 formulas, and regarding topological, workload and policy aspects. Kubernetes organizes containers in a multi-level, hierarchical way. In Kubernetes terminology, a cluster is composed of a set of nodes, each node is composed of a set of pods, and a pod is composed of a set of containers. A container is intended to host a single microservice, realizing a part of the functionalities of a specific service. A service is not statically associated with a particular pod, but its traffic may be routed to different pods depending on the activities of the scheduler. This mechanism transparently decouples the containers from the services, providing robust availability.

The FedUp! platform is intended to automatically deploy Federation Infrastructures (which have been declaratively specified) via Kubernetes. This implies a possible coupling between the development of a Federation Infrastructure and Kubernetes, based on the following observations. 1. Kubernetes uses its own network models for inter-service communications.

For example, it offers a DNS service as a pluggable component. This technique transparently masks the dynamic routing from a service to potentially different pods. As a consequence, differently from traditional models, services need to query the DNS service frequently. 2. Kubernetes needs a declarative proposition to be prepared for every single definition of a container, service or pod used by the infrastructure.

In order to decrease the coupling between the development of services and (specific versions of) Kubernetes, we exploit the flexibility of its network model.

In particular, FedUp! adopts a traditional network model (i.e. using static IP address and ports). This is realized by defining a formalized model for the definition of a Federation Infrastructure, and an automatic generator of declarative primitives to be used for the deployment of a federation.

With this solution, the declarative propositions influencing a deployed Federation Infrastructure (e.g. numbers of replicas for pods, minimum policies for machines) need not be considered by the developers of a Federation Infrastructure. Given that reasonable declarative propositions can be chosen by FedUp!, developers are lifted from the burden of acquiring the necessary knowledge of, and re-implement services to fits to, a specific Kubernetes network model.

Federating Heterogeneous Clouds

In this section, we focus on the two basic mechanisms for creating a Federation and for the joining/acquisition of a cloud (actually a tenant) to a Federation. The other actions provided by FedUp! are realized in analogous ways. Figure 2 provides an activity diagram describing the fundamental phases involved in these two processes, which are then detailed in the following subsections. While creation only involves the originator cloud and FedUp!, joining a Federation Fed is seen as a two-step process in which a cloud Cld (actually a tenant in a cloud) issues a request via the Join action, also providing information on what it can contribute, and Cld enters Fed when the latter accepts a specific request, via the Acquire action, or interrogates the FedUp! Search service about the presence of candidate clouds characterised by specific features. To support this kind of mechanisms, join and acquire requests are associated with a collection of tags expressing cloud features, e.g. the types and quantities of resources or services a cloud can contribute to a Federation, the SLAs of the contributed services, or even the intention to join a specific Federation. FedUp! will therefore publish a dictionary of managed tags and their admissible values. For example, in Figure 1 in Section 3, we have indicated that clouds A and B had issued specific requests to participate in Fed2 and Fed3, while cloud C has issued a request characterised by two specific values for two different tags.

Similarly, a Federation Fed can directly acquire a cloud, based on previous notifications of interest for some features, so that if a matching cloud issues a request to participate in Fed, it is automatically acquired. Criteria for accepting a new member are proper to any Federation and need not be public. For example, an initial set of governmental agencies can decide to set up a version of FedUp! and accept only clouds from other public agencies, while a European initiative for a federated cloud could accept only clouds managed by agencies at governmental level from EU nations.

Each cloud accepted in a Federation Fed will generate a partition of its resources to act as tenant for Fed. In principle a cloud can participate in several federations, e.g in Figure 1 cloud A participates both in Fed2 and Fed3, and even present different tenants to the same Federation, e.g. cloud B participates in Fed3 with two tenants, for example one for high performance resources and one for less stringent SLAs.

Given a single Federation, the shared resources can be partitioned into the infrastructure resources used to host the Federation itself, and the cloud resources that can be offered, or acquired, by the individual clouds. Unless differently specified, we use the term resource to refer to an infrastructure resource. Analogously, the term service refers to an infrastructure service rather than a service offered or acquired by the federation members. In this paper we are not specifically concerned with the implementation details of a Federation Infrastructure, but we just mention the following:

-A Federation Infrastructure is typically realized through a service named Workload Manager that interacts with a centralized registry, for storing and assigning cloud-resources and cloud-offerings. -Services within the Federation Infrastructure may be relative to networking, monitoring, billing and authorization aspects. -A Federation Infrastructure may be capable of federating heterogeneously in terms of the particular PaaS solutions used by the individual clouds. -A Federation Infrastructure may have a (logically) centralized architecture.

Figure 3 shows the UML metamodel for dynamic, service-oriented, network Federation Infrastructures, using a containerized microservice architecture, in which the communication is realized over IP addresses/ports. In particular, a FedInfrastructure is associated with a non-empty set of instances of Service, Fig. 3. The metamodel for the federation infrastructure each described by a static IP address and one or more instances of Port to be used by other services. Each service results from the aggregation of a number of instances of MicroService, each in turn associated with a single port and with a single ContainerImage. The relation is also shown between the infrastructure metamodel and the general model of federations, which need to be conformant to some infrastructure and composed of tenants belonging to clouds.

A particular instance of this model can be translated into a proper set of declarative propositions: together with the declarative propositions provided by FedUp! (Section 4), they form the necessary information for a cluster to deploy and manage the federation. A Federation Infrastructure deployed by FedUp! has the following characteristics:

-A deployed Federation Infrastructure consists in a set of deployed services.

-A deployed service has network visibility among any other deployed service.

-A deployed service is composed of one or more microservices, each one deployed on a different container.

Creating a Federation

Figure 4 shows a sequence diagram presenting the fundamental steps for creating a federation. An administrator of a tenant virtual machines dedicated to form a Kubernetes cluster (through the operation Create Cluster, not further detailed here). In particular, a Service Orchestrator VM is dedicated to host a Kubernetes Master, while the other ones are set up to become Kubernetes nodes. The Federation Configurator is at the same time a SaltStack slave of FedUp.ConfiguratorMaster and a SaltStack master of the machines composing the cluster.

Figure 5 shows the considered SaltStack dependencies: a black triangle represents a slave relation with respect to a SaltStack master connected to the line entering to the triangle, while a star represents a virtual machine which is part of a Kubernetes Cluster. After the Kubernetes cluster is created, the Service Orchestrator is remotely configured (arrow 4 of Figure 4) to retrieve from FedUp! the necessary files to deploy the Infrastructure Services. In particular, it is shown how the FedUp.ContainerHub provides the containers relative to the microservices composing the Infrastructure Services. Similarly, the Service Orchestrator retrieves the configuration files for the pods, containers and services (not shown) from the FedUp.ServiceRegistry.

Joining a federation

Figure 6 presents the fundamental steps for joining a federation, from the perspective of a new member. The administrator of a Tenant Ten2 of cloud Cld2 (not federated yet) communicates the availability to join a federation, also providing a set of tags, describing its possible contributions. An ID id offer x is sent back to the administrator, to be used in a polling request for the state of its offering. Assuming that at a certain moment an existing Federation FedY accepts this join offering (either as a consequence of an administrator explicit action, or of a standing search for matching offerings) and acquires the originator tenant, the ID of FedY will be returned to Ten2 on the subsequent request. 7 shows the process for a Federation Y, identified by id offer y, to acquire a cloud Cld2. Federation Y looks up the FedUp.Registry for a set of acquirable tenants, based on a set of tags ("filter"). The set is populated based on an interaction between the registry and FedUp.Fed. In particular a subset of the available offerings, arranged into a list of IDs, ([. . . ,id offer x,. . . ]) is returned to the Federation. Federation Y can communicate its intention to acquire the offering identified by id offer x, which had been published by Cld2, to the Registry, which forwards the request to FedUp.Fed, that will complete the join process. An acknowledgement is sent back to Cld2, communicating id offer y. FedUp! provides a lean PaaS approach to the flexible deployment and management of federations of clouds, opening the way to the notion of Federation as a Service, whereby a central platform will maintain images of predefined configurations that an administrator can decide to install and activate on a managed portion of a cloud. In principle, any cloud user could exploit the resources obtained by joining a federation to federate them in turn within existing federations, or to start a new federation.

The platform relies on notions of containers, microservices, configurations and clusters made popular by technologies such as Docker, Kubernetes,and Saltstack, which are adopted in its current specification, but is in principle not tied to them, as it only requires that the tenant designated to start a federation will allow the installation of a virtual machine with an initial configurator, which will then execute the needed operations on the tenant. The current working prototype will be subject to extensive evaluation.

In this line, one can envision a marketplace of federation services, where also specific services that a single federation wants to offer can be defined and offered for configurations. For example, one could offer specific forms of workload management, or of data security across the different members of the federation.

In this paper we described how instances of a metamodel for Federation Infrastructures to be generated are memorized by FedUp!. Moreover, we described how tags can be used to facilitate a targeted encounter between individual clouds and Federations. It is possible to further develop these concepts. One can think of supporting the sharing of the definition of services among different types of Federation Infrastructure. In this context, tags could be associated with specific definitions of services, for example to assess compatibility with other services, or with different configurations of the same service to be used in different scenarios. In this manner, a customizable Federation Infrastructures could be deployed by blending and re-using (partially or integrally) services memorized by FedUp! with a modular approach. The same concept could even apply to microservices.

Finally, FedUp! could provide the possibility to a tenant administrator to specify parameters to be used in the process of creating a Federation. For example, by allowing to choose the desired number of replicas for services, the possibility would be offered to provide a parametric tuning of the robustness, in terms of availability, of the deployed services.

  FedUp.Registry maintains information on the generated Federations and on the individual clouds that want to offer or use services offered by FedUp!. -FedUp.ServiceRegistry maintains the information on services in terms of configuration and set of microservices. -FedUp.ContainerHub maintains the images of the containers relative to the various microservices. -FedUp.ConfiguratorMaster is responsible for ensuring that Federations generated with FedUp! be properly configured in terms of the presence of files, installed packages and services running to manage that Federation. More information about this component is given in Section 4. In particular, FedUp.Registry contains: -Data on generated Federations together with the corresponding tags describing their main features. The tags are assigned by the Federation owner at generation time, but can be changed during its construction and are used by the search functions made available for the individual clouds to search for Federations matching the membership requirements of the individual cloud. -References to the individual clouds that want to share resources through the FedUp! platform with the corresponding tags describing their main features. Tags are assigned by the cloud owner during the registration to FedUp! and are used by search functions made available for the Federations to select individual clouds matching the Federation membership requirements. -The map of participant clouds to individual Federations and the map of clouds available to federate.

Fig. 1 .

 1 Fig. 1. A conceptual overview of the proposed solution

Fig. 2 .

 2 Fig. 2. An overview of the main processes in FedUp!.

Fig. 4 .

 4 Fig. 4. The sequence diagram for creating a federation

Fig. 5 .

 5 Fig. 5. Visualization of the SaltStack dependencies: a black triangle represents a slave relation with respect to a SaltStack master connected to the line entering to the triangle. A star identifies an element of a Kubernetes cluster.

Fig. 6 .

 6 Fig. 6. The sequence diagram for a tenant joining a federation

Figure

  Figure7shows the process for a Federation Y, identified by id offer y, to acquire a cloud Cld2. Federation Y looks up the FedUp.Registry for a set of acquirable tenants, based on a set of tags ("filter"). The set is populated based on an interaction between the registry and FedUp.Fed. In particular a subset of

Fig. 7 .

 7 Fig. 7. The sequence diagram for a federation acquiring a tenant

Table 3 .

 3 The List of utilities and actions in FedUp!

	Utility and Action	Description
	FedUp.Fed	Services for federation management.
	FedUp.Fed.Create	To create a new Federation. The cloud creating the new
		Federation becomes the owner.
	FedUp.Fed.Update	To change/update a Federation features, tags included.
	FedUp.Fed.Dismiss	To dismiss a Federation. All clouds, except the owner,
		need to quit.
	FedUp.Fed.Acquire

  Ten1 in a cloud Cld1 issues a request to FedUp.Fed (namely to its Create action) for creating a new Federation (arrow 1). The request contains the desired federation type (among the available Federation Infrastructure solutions) and the credentials usable to interact with Cld1 's IaaS Resource Manager. FedUp.Fed is capable of interacting with heterogeneous clouds trough a virtual interface exposed by an adapter service provided by FedUp! , using plugins associated to different IaaS solutions.FedUp.Fed uses the received credentials to instantiate a Virtual Machine inside Ten1 (arrow 2). This VM, named Federation Configurator, is a Salt-Stack slave of the FedUp.ConfiguratorMaster, located on the FedUp! side. The FedUp.ConfiguratorMaster remotely configures the Federation Configurator (arrow 3) so that it can in turn instantiate and configure inside Ten1 a set of

http://www.fogbowcloud.org/

http://zentera.net/

Acronyms for [Software, Platform, and Infrastructure] as a Service.

https://www.docker.com/

http://saltstack.com/

https://github.com/kubernetes/kubernetes/blob/master/docs/design/README.md

YAML Ain't Markup Language,http://yaml.org/

Acknowledgments

This work has been supported by the EU H2020 Programme under the SUNFISH project, grant agreement N.644666.