Keywords

1 Introduction

As the future of grid computing, cloud computing has become a popular environment of equal opportunity for enterprises of all sizes as “developers with innovative ideas for new Internet services no longer require the large capital outlays in hardware to deploy their service or the human expense to operate it.” [1]

As a new paradigm, cloud computing builds upon existing technology in order to bring forth clear advantages exposed as core cloud characteristics [2] and technical ones [3] for delivering infrastructure at reduced costs to companies, a direct consequence being that “an increasing number of SMEs […] are thinking of migrating some aspects of their operations to the cloud.” [4]

Unfortunately, a simple migration to the cloud is not possible, as it does not necessarily provide efficient exploitation means for this new environment. Additional enablers, like infrastructure and platform abstractions, and cloud management support are required for an efficient cloud adoption in the case of small and medium-sized enterprises (SME s), in order to achieve the desired efficiency and ease of use for cloud resources utilization and management.

Furthermore, despite the great progress achieved in the adoption of cloud computing, and the growing number of applications that are exposing their services in a cloud environment, there is still an increasing demand for integration as these newly deployed services are rather perceived as “a mish-mash of SaaS silos and cloud islands, with very little attention paid to data consistency and integration, and even less to policy management and oversight.” [5]

Cloud management is a collection of technologies and software which enable control and operation of cloud applications through a series of services ranging from monitoring to security and privacy management, resource provisioning, application scaling, etc. Focusing on improving the efficacy of the “in the cloud” activities and facilitating easy access to the cloud environment by hiding any unnecessary layers, cloud management complements existing PaaS solutions and simplifies cloud adoption through infrastructure management. A series of services could be identified in the context of cloud management, including resource provisioning, monitoring and reconfiguration, or service level agreement (SLA) and quality of service (QoS) management.

While existing PaaS and cloud management solutions focus on providing enterprises of all sizes easy access to cloud environments and push on cloud adoption, cloud governance takes a more directional role by steering the underlying cloud management solutions according to a set of predefined policies, processes and procedures.

The cloud broker, “an entity that creates and maintains relationships with multiple cloud service providers ” [6], exists in close relation with both cloud management and cloud governance, exposing functionalities that are relevant for both layers. Current cloud broker solutions focus mainly on cloud management aspects by providing more infrastructure brokering and less service brokering.

Unlike cloud management which is in charge of low level processes like resource provisioning, or resource monitoring, cloud governance enables formation of virtual enterprises, and controls all high level processes, including service lifecycle management , security, privacy, billing and others, spanning across execution and operations support. It is envisioned as a central entity whose purpose is to enable both service and data integration and create a unitary ecosystem where applications can be created, managed, discovered and can easily interact with each other.

Acting at the software as a service (SaaS ) level, cloud governance revolves around providing service management and service lifecycle automatio n, complemented by a marketplace of services, and integrated with specific operations support in order to provide service across this dynamic and heterogeneous environment.

The cloud service lifecycle is central for cloud governance as it spans on all service layers and it also interfaces with cloud management. Its different aspects that could be considered and extended include, but are not limited to, service templates, offerings, contracts, service provisioning, runtime maintenance and service termination.

In the context of cloud governance, the cloud service brokering is the core service offered by the governance environment as it facilitates the consumer–producer model in that it enables service identification, selection and contracting, successfully exposing the three principles introduced in a later section of this chapter; and thus creating virtual environments for improved exposure of cloud services. In order to achieve cloud service brokering, a series of additional components are required, components that are linked with a cloud service ontology which is complementary in that it enables extensible semantic service descriptions.

2 Cloud Brokerage

The importance of cloud brokerage was identified at the early stages of cloud computing development, in a Gartner press release [7]. “The future of cloud computing will be permeated with the notion of brokers negotiating relationships between providers of cloud services and the service customers, ” as L. Frank Kenney specified in the aforementioned document. In close relation with existing developments for cloud management and service lifecycle support solutions, different definitions for the cloud broker were identified and further refined.

The Gartner document first identified that the cloud broker “might be software, appliances, platforms or suites of technologies that enhance the base services available through the cloud. Enhancement will include managing access to these services, providing greater security or even creating completely new services.” [7]

In a subsequent definition from Gartner’s IT Glossary, the cloud broker was identified as an innovative serv ice:“cloud services brokerage (CSB) is an IT role and business model in which a company or other entity adds value to one or more (public or private) cloud services on behalf of one or more consumers of that service via three primary roles including aggregation, integration and customization brokerage. A CSB enabler provides technology to implement CSB, and a CSB provider offers combined technology, people and methodologies to implement and manage CSB-related projects” [8].

The National Institute of Standards and Technology (NIST) cloud computing reference architecture document [9] puts the cloud broker in relation with the increasing complexity required for integration of cloud services, and the cloud broker is defined as “an entity that manages the use, performance and delivery of cloud services and negotiates relationships between cloud provider s and cloud consumers ”.

A resource-oriented point of view for the cloud broker was identified in the white paper [10], where the cloud broker was mentioned as an agent that “has no cloud resources of its own, but matches consumers and providers based on the SLA required by the consumer. The consumer has no knowledge that the broker does not control the resources”. In the vision of the cloud computing use cases group (CCUCG) , the cloud broker has some specific responsibilities in delivering hybrid clouds, where the cloud broker coordinates multiple clouds by federating “data, applications, user identity, security and other details” [10].

A distinctive definition was offered in a document from the DISA Department of Defense, where the responsibilities of an enterprise cloud service broker (ECSB) were identified to “manage the use, performance and delivery of cloud services, and negotiate relationships between cloud providers and cloud consumers”.Footnote 1

In another cloud computing strategic paper [6], the cloud broker was identified as “an entity that creates and maintains relationships with multiple cloud service providers. It acts as a liaison between cloud services customers and cloud service providers, selecting the best provider for each customer and monitoring the services”.

Three main CSB-related businesses were identified by Gartner [7] and adopted in the NIST reference architecture document [9] (see also Fig. 11.1) as:

Fig. 11.1
figure 1

The NIST conceptual reference model. (Source: [9])

Full size image

  • Cloud service intermediation Service intermediation is related with various means for enhancing services, including SLAs and QoS- related activities, security and identity management support, managed access to cloud services, and others.

  • Service aggregation As a core capability, the CSB is identified as being able to retrieve, combine and integrate multiple services in one or several services. During the aggregation process, new services could be offered, together with the necessary means for data integration and security between the cloud consumers and multiple cloud providers .

  • Cloud service arbitrage In the case of service arbitrage, the cloud broker has the ability to dynamically choose services during the aggregation process. Different agencies and/or service repositories could be used for this process, in relation with some specific selection mechanisms.

2.1 Cloud Resource Broker

The cloud resource broker is necessary, according to the definition from [7], to establish relationships between consumers and providers. As the initial interest in cloud developments was primarily oriented towards resource consumption, early developments were highly oriented towards resource brokering, including negotiation and provisioning.

Current research being conducted focuses either on brokering architectures (all cloud service models) or on SLA s, in close relation with the QoS , in order to support consequent activities (monitoring, scaling, etc.).

Acting on top of the Infrastructure as a Service (IaaS )layer, the Gridbus projectFootnote 2 developed a resource broker that was able to perform negotiations with resource providers [11], where a “resource on a grid could be any entity that provides access to a resource/service”.

Different approaches into SLA s were performed in [12], where the SLAs were broken into SLA objectives (SLO s) which enable individual resource monitoring based on performance metrics, and in [13], where SLAs are used for on-demand service provisioning, or in [14], where they are combined with policies for automatic negotiation. QoS -based approaches focused on mechanisms for resource allocation were covered in [15] and research into QoS metrics was performed in [16].

Additional standards are being developed to support service descriptions, of them the most noteworthy being open cloud computing interface (OCCI) Footnote 3 which was originally intended to work at IaaS level. However, it can be easily extended to work at different deployment levels, too. Built to use OCCI , SLA@SOI Footnote 4 was designed to tackle IaaS SLA s.

2.2 Cloud Service Broker

The CSB offers a full implementation of the brokering component, usually at the superior level of cloud governance, thus providing functionality related with service intermediation and service aggregation , eventually via service arbitrage [7, 9]. The CSB facilitates service consumer s easy access in order to search, retrieve and contract services (service intermediation). By doing so, it enables creation of virtual marketplaces where trading can be done (enabling service arbitrage), allowing applications that were previously running in isolation to be integrated (via service aggregation) within the larger cloud ecosystem, either as a virtual enterprise or a cluster of partners.

In a document detailing the European Union’s vision for the future of cloud computing [17] the CSB was identified as an important element that is needed in order to foster competitiveness in the European space as, currently, it has fallen behind the USA on the cloud computing market. Moreover, a significant semantic support is necessary to facilitate better search of heterogeneous information, and thus there is a need for the development of a semantically enabled cloud services registry and repository.

Built on top of existing cloud taxonomies [2, 18], and cloud resource ontology [19], such a registry will enable the core requirements for the CSB, and provide further integration with cloud specifications, including OCCI [20, 21] Topology and Orchestration Specification for Cloud Applications (TOSCA ), Footnote 5Open Services for Lifecycle Collaboration(OSLC 5), CloudML [22], or even ThingML [23, 24], technologies which aims to enhance the portability of cloud applications and services.

Two distinctive approaches are required for developing a fully specified registry for cloud services—resource representations and service representations.

2.2.1 Resource Representation

The FP7 mOSAIC project Footnote 6 developed an ontology for cloud resources, closely following the Oracle cloud resource model and OCCI specifications [19]. Specifying that “the Resource class is the most complex in the mOSAIC , since, following the OCCI documentation, in Cloud Systems everything is a cloud Resource”, the ontology offers a good coverage for cloud resources, establishing at the same time some basic mechanisms for interrelations between services and resources.

The resource representation from the mOSAIC project was fully exploited by a semantic engine and integrated in the development of a semantically enabled, agents-based cloud management solution [25]. However, the mOSAIC cloud agency was rather concerned with the development of a brokering mechanism , in order to allow advanced mechanisms for resource provisioning and SLA monitoring [26, 27].

Other approaches include the ontology-based resource selection service (OReSS) mechanism described in [28], together with a resource selection engine; a selection mechanism for resources, based on user requirements and specified SLAs [29]; an extended representation of cloud resources, in the context of the Cloud@Home initiative [30]; or the definition of a meta-language, CloudML , to support resource provisioning in the cloud [22].

2.2.2 Service Representation

While the mOSAIC approach is close enough to the IaaS and PaaS levels, additional information is required in order to have complete specifications of services at the SaaS level, and to fully enable the semantic registry that will allow the activation of the intermediation-aggregation-arbitrage mechanism.

Table 11.1 Relevant service brokering operations. (Source: [36])
Full size table

Key concepts, including those of services, business, computing, quality and service types, were identified in the analysis of Sorathia et al. [31] in order to capture service representations. This analysis, complemented by previous results related with cloud taxonomies [18, 32], or the service-oriented mechanisms, as those from [33, 34], offered the necessary support for the identification of the core concepts in the development of a cloud services ontology, including service models, deployment models, service capabilities and functional properties, service availability, non-functional properties, SLAs, security and QoS , service characterization, service classifications, and service resources [35]. Closely related with these findings, a series of relevant brokering operations could be specified, as shown in Table 11.1, and detailed in [36].

3 Cloud Management

Cloud management revolves around the use of existing technologies and software in order to expose services which facilitate easy cloud migration by providing the means to create and manage portable cloud applications. In close relation with the existing PaaS solutions, cloud management focuses on alleviating users of the need to know all cloud layers’ details by bypassing the unnecessary ones, and thus reducing the complexity of the development and the required time.

The necessity for cloud management was first described in a set of distributed management task force (DMTF) and CCUCG documents [10, 37, 38], which underline its role in cloud adoption and existing relationships with other cloud enablers while identifying its main focus in providing automation of services (e.g. resource provisioning), SLA management, resource monitoring and others.

Different cloud architectures and use-cases were considered, described and discussed during the last years for achieving a complete specification of various operational aspects of cloud computing, both at IaaS and SaaS levels. Thus, cloud management activities were identified as spanning over the two aforementioned layers. However, we are going to make a clear distinction between management activities at IaaS level, and corresponding activities at SaaS level, and limit cloud management to the IaaS level, while cloud governance includes specific management activities for cloud services.

Developed by IBM, the monitor-analyze-plan-execute (MAPE) cycle [39], along with the MAPE-knowledge base (MAPE-K ), fits perfectly with cloud management in terms of desired automation and functionality, thus setting the guidelines for future developments.

The importance of SLA s is further highlighted in the work of Emeakaroha et al. [40] where he stresses that “prevention of SLA violations avoids unnecessary penalties providers have to pay in case of violations […] interactions with users can be minimized”.

Through the specification of QoS requirements, SLAs ensure correct and complete resource specification as well as offer the basis upon which monitoring can be performed as well as enable application reconfiguration based on a set of policies which use monitoring information in order to trigger [41] (Table 11.2).

Table 11.2 Functionalities and requirements for cloud management and cloud governance
Full size table

3.1 Requirements for Cloud Management

Current requirements revolve around the management of cloud resources and the facilitation of easy integration within other cloud management solutions. In the case of cloud resource management, the focus is on:

  • Resource provisioning: is the process of selecting the best cloud resources that fulfil the cloud application requirements. It is a process that runs on all deployment levels (IaaS, PaaS and SaaS ) and is achieved by using existing parameters which help to define cloud resources in order to filter through the offers coming from cloud vendors, thus offering brokering capabilities to the client entity; the Execute phase from the MAPE-K model

  • Resource configuration: involves the configuration of the provisioned resources as per application requirements, making sure that the environment is fit for application deployment; the Execute phase from the MAPE-K model

  • Application deployment: is the final step which facilitates a running cloud application and involves the deployment of all application components and resolving of all their dependencies as well as additional application configuration which must be done, additionally, when migration is perform, it must handle data migration as well; the Execute phase from the MAPE-K model

  • Resource monitoring: any cloud management solution must offer the monitoring of the provisioned cloud resources either by using vendor specific APIs to retrieve monitoring information or by installing custom software to achieve it. Monitoring is in close relation with SLA management and application reconfiguration; the Monitoring phase from the MAPE-K model

  • SLA management: involves the storage, modification and retrieval of brokered SLA s which happens upon provisioning, monitoring or reconfiguration of the cloud application; the Plan phase from the MAPE-K model

  • Application reconfiguration: is focused on analyzing monitoring information (metrics) and correlating it with information found in SLA s (policies) in order to trigger application reconfiguration: scaling up or down, replacing resources which breached SLAs; the Analyze phase from the MAPE-K model

Table 11.3 Cloud management solutions
Full size table

In the case of integration within other cloud management solutions, a good cloud management solution must provide interfaces (e.g. REST) and APIs through which its functionality can be accessed and executed.

3.2 Reference Architectures

The Open Cloud Standards Incubator from DMTF produced a couple of white papers that are most relevant for the cloud management area: a reference architecture, covering both aspects related with cloud resource management and cloud services management [37], and a companion use-case document [38]. While discussing relevant cloud management issues, the DMTF couple of documents set clear relations with aspects that are most appropriate for cloud governance.

More pertinent to cloud management at IaaS level, the DMTF Cloud Management Working Group developed a set of documents that deal with central aspects for resource management at infrastructure level. In the cloud infrastructure management interface (CIMI) model the typical IaaS resources “are modeled with the goal of providing Consumer management access to an implementation of IaaS and facilitating portability between cloud implementations that support the specification” [42].

A similar approach was used by the open grid forum (OGF ) OCCI -WG with the OCCI specification, initially developed to address IaaS-related management tasks, and extended “to serve many other models in addition to IaaS, including PaaS and SaaS ” [20].

A number of cloud management solutions exist, most of them being strictly limited to offering basic cloud management functionality like resource provisioning and monitoring, few also being hybrids between cloud management and PaaS as described in Table 11.3.

4 Cloud Governance

Cloud governance, thought as a natural extension of SOA governance, is an essential component for further development of an environment able to offer superior facilities for SME s, on top of the core cloud characteristics. These facilities, built around cloud services lifecycle support, and strongly backed by the exploitation of a semantically enabled cloud services knowledge base, will allow the development of different virtual environments where SME s could cooperate and develop tailored solutions, acting as a unique entity while they are still preserving the identity of their services.

These virtual environments, either virtual enterprises or virtual clusters, allow the implementation of different scenarios of grouping and collaboration between partners, requiring relevant technological support, and business and operational support, both aspects being integrated with the cloud service lifecycle support.

As mentioned in [43], a series of research challenges are extremely relevant in the context of the virtual environments activated by a cloud governance solution, including novel cloud architectures, automated service provisioning, data security and software frameworks, [44], together with open standards interface, delivery of services supported by SLA , or security in various service delivery models [45].

4.1 Requirements for Cloud Governance

An IBM RedBook identifies cloud computing as an enabler of a series of business models, most relevant for cloud service providers , where “an ecosystem of businesses and individuals […] extends the reach of cloud service providers by expanding the breadth of services that are offered and addressing niche or specialty markets and geographies” [46]. In the same IBM document a series of adoption patterns for their cloud computing reference architecture (Fig. 11.2) were identified, with two distinct perspectives: the IaaS-based (IaaS as an entry point), and the SaaS -based one. Hosting, aggregation and ‘white label’(rebranding of services) are seen as the most relevant choices a service provider will adopt.

Fig. 11.2
figure 2

The IBM cloud computing reference architecture with service creation details. (IBM CCRA, source: [47])

Full size image

Automatic aggregation and clear identification of policies, parameters and processes were also identified as being most relevant in the context of cloud governance [47]. Together with the patterns described in the IBM White Paper [48] and the set of steps that were identified for a governance framework for cloud security in [49], a set of four core requirements for cloud computing were identified, including security and privacy, lifecycle automation, service management and business standards [43, 50].

Security is a core requirement that also has implications in privacy and standards. Security considerations must cover both application developers and cloud providers . An important issue related to security is the lack of disclosure of security-related information of cloud providers.

Privacy is an important concern as many SME s deal with sensitive information which poses migration concerns related to the storage and handling of this information as well as legal implications in terms of contracts and governmental laws.

Another core requirement is standards, as most cloud providers implement their own proprietary technologies and do not always adhere to existing open standards thus making interoperability hard to achieve.

The last one, lifecycle management, is a core requirement which most cloud provider s do not cover. It refers to the ability to manage various cloud applications in terms of, e.g. versioning, updating, monitoring, etc.

4.2 Relationship with Cloud Management

Standards like ISO/IEC 38500 for IT governance offer a foundation on which cloud governance can be built and can further allow interaction with frameworks and industry standards. This, in turn, enables interaction between cloud governance and cloud management through bridges that these standards facilitate.

Through the Monitor-Evaluate-Direct cycle brought by ISO/IEC 38500, one can establish links with the MAPE-K cycle, as defined by IBM [39], in order to better express the symbiosis between cloud governance and cloud management and how their services and functionality is complementary, as shown in Fig. 11.3.

Fig. 11.3
figure 3

The interrelationships between the MAPE-K and ISO 38500 models

Full size image

4.3 Lifecycle Support

According to Bennett et al. [51], eleven stages could be identified in close relation with cloud governance requirements, including from a functional point of view service development, testing, deployment and maintenance, service usage and monitoring, service discovery, and service versioning and retirement. Each of these stages could be specified in close relation with cloud service lifecycle steps, as identified in [37, 52].

In [37] the cloud service lifecycle is presented rather from the perspective of cloud management. The description from [52], as presented in Fig. 11.4, is more comprehensive, offering a clear identification of the stages that are related with service template and specification (design time operations), service discovery and composition (provisioning operations), service deployment and execution (deployment and execution operations), and service versioning, archiving and retirement. With this level of details, links with the business and operations support could be easily specified.

Fig. 11.4
figure 4

Extended cloud service lifecycle. (Source: [52])

Full size image

Few solutions currently exist for supporting cloud service management. In the approach from adaptive computingFootnote 7, automation is central for the implementation of cloud service lifecycle, with a set of key steps consisting in agile service delivery, automated management, and adaptive cloud resources and services.

Different solutions covering various aspects related with cloud service lifecycle exist, including the BMC Cloud Lifecycle ManagementFootnote 8 (with particular attention for provisioning operations) [53], WSO2 Governance RegistryFootnote 9 (with specific interest for design time operations, and service discovery), or the strategic white paper from Enstratus DevOpsFootnote 10.

Clotho, the service lifecycle manager from the Morfeo project [54], offers facilities for service orchestration, while offering support for automated “service deployment and the dynamic provisioning of services”Footnote 11. The PaaSage projectFootnote 12 aims to “develop an open and integrated platform to support the lifecycle management of cloud applications”Footnote 13, while the MODAClouds project intends to provide “quality assurance during the application life-cycle and support migration from Cloud to Cloud when needed”Footnote 14.

4.4 Service Registry

In order to meet the various requirements set for cloud governance, specifically for the service lifecycle, some support for the storage and retrieval of service-related information is necessary, thus underlining the need for a specialized service registry.

This service registry provides the means for the creation of virtual enterprises by providing support for collaboration between enterprises and, consequently, support for the composition of their services, as well as provide the means for cloud application automation for tasks related to application scaling, migrating, etc. Therefore, a semantic approach would be most suited in order to enable this functionality, as well as to provide semantic interoperability, which can be integrated both at cloud management and at cloud governance levels extending the level of automation that is achievable and enhancing the cloud service lifecycle.

While, at IaaS level, semantic interoperability is focused around resources [19] as was investigated in the FP7-ICT Project mOSAIC Footnote 15, PaaS semantic interoperability was considered in FP7 Project Cloud4SOAFootnote 16. At SaaS level, semantic interoperability supports creation of cloud service marketplaces which enable service discovery, selection and composition.

The functionalities of a cloud governance service registry can be broken in:

  • Service management—the registration, updating and removing of services and service related information both syntactic and semantic

  • Semantic discovery—the ability to use semantic information of a service (functional and non-functional information) in order identify services

  • Semantic filtering—the ability to manipulate semantic information of a service in order to achieve service selection

  • Execution support—support execution activities though service information

Essentially, the service registry provides a catalogue of existing services on top of which governance clients, or even the governance itself, can run service discovery in order to support various stages of the service lifecycle from the planning stage to the execution and termination stage of cloud services.

5 Multi-Agent Approaches for Cloud Governance and Management

Multi-agent systems are complex asynchronous systems composed of a minimal of two homogeneous or heterogeneous agents which work in order to achieve some set of goals. Each agent composing the system can have various degrees of autonomy when deciding what to do and how to do it (individually or cooperatively, self-interested or benevolent). On the other side, having a completely asynchronous system can lead to it being highly distributed and, possibly, highly fault tolerant. Because of these abilities, multi-agent systems are ideal for the development of highly distributed, collaborative, autonomic applications, especially when dealing with cloud environments where there is a mix of heterogeneous technologies and where adaptability is critical.

According to D. Talia [55], “the convergence of interests between multi-agent systems that need reliable distributed infrastructures and Cloud computing systems that need intelligent software with dynamic, flexible, and autonomous behavior will result in new systems and applications”. Thus, an increasing interest in using multi-agent approaches for cloud applications exists. Furthermore, Sim states that “agent-based cloud computing is concerned with the design and development of software agents for bolstering cloud service discovery, service negotiation, and service composition” [56].

Multi-agent systems that handle various real life problems can benefit from cloud computing. For example, the cloud based multi-agent system described in [57] was used for the management of dynamic traffic environments by taking advantage of the available on-demand computing, storage and networking put forth by the cloud environment.

Another interesting approach was Unity, a multi-agent decentralized architecture for autonomic cloud computing, designed for the study and testing of ideas related to autonomic system, which features self-healing, real-time self-optimization and goal-driven self-assembly [58].

5.1 Multi-Agent Approaches for Cloud Management

Cloud management represents an important business segment of cloud computing, many enterprises offering cloud management solutions. From a multi-agent point of view, most agent solutions address parts of the problems, but few address it as a whole.

One of the most representative solutions for agent-based cloud management is mOSAIC’s ’s Cloud Agency [59]. Part of the mOSAIC project , the Cloud Agency offers resource provisioning and monitoring across public and private major infrastructure cloud providers and is “in charge to broker the collection of Cloud resources from different providers that fulfills at the best the requirements of user’s applications” [41].Another study focuses on platform level services as well as other native software applications providing the ‘as’ part of the +Cloud (masCloud ) platform which is in charge of resource management, performing on-demand resource scaling [60].

One important aspect of cloud management is resource provisioning and in this regard there are many directions. Some multi-agent solutions deal with negotiation, though actual cloud resource negotiation is not currently possible with most cloud providers. Others focus on the discovery, selection and composition of cloud resources.

For example, the work performed in [56] highlights the use of agents in order to provide cloud resource management with focus on service discovery, negotiation and composition achieved through cooperating agents performing complex negotiations in order to provide a cloud search engine.

An approach for Web service discovery in the cloud environment is presented in [61] where agents, coupled with specific algorithms for matchmaking and ranking of Web services, are used for finding the best candidate that corresponds to the description provided by the client while considering QoS parameters of the Web services.

Cloud resource provisioning is also addressed in [62] through a distributed negotiation mechanism where agents act on behalf of the consumers and negotiate contracts which allow single-sided termination (consumer’s side) upon paying a certain price. Semantic cloud resource negotiation is conducted in [63] where a multi-agent system is used in order to facilitate the adaptation and coordination of application execution across various cloud providers through a set of scheduling policies in order to achieve both consumer and producer satisfaction.

In their work [16], Cao et al. describe a multi-agent cloud management architecture focused on supporting QoS-assured cloud service provisioning and management. Another QoS-oriented cloud management solution is presented in [64] where “an automatic resource allocation strategy based on market Mechanism (ARAS-M )” is used, and “a QoS-refectitive utility function is designed according to different resource requirements of Cloud Client” and is combined with a genetic algorithm for automatic price adjustment.

Security considerations using agent-based approaches where a security audit system makes use of intelligent autonomous agents in order to tackle cloud-specific problems like infrastructure changes were presented in [65].

5.2 Multi-Agent Approaches for Cloud Governance

As it is a new research topic, there are few approaches in which multi-agents address issues related to cloud governance. Starting from mOSAIC’s Cloud Agency, the work carried in [50] extends its functionality and complements it with specific governance functions.

Since cloud governance focuses on providing business aspects and one important one is virtual enterprises the work performed by Carrascosa et al. [66], though not being directly linked to cloud computing, is about THOMAS which is an open architecture which builds on the foundation of intelligent physical agents (FIPA) agent architecture in order to facilitate the design of virtual organizations using a service-oriented approach where agents are in charge of service management.

In order to enable virtual enterprises, cloud governance must facilitate easy composition of cloud services so that their developers and owners can benefit from adhering to new business models. In this regard, automated cloud service composition has been efficiently achieved in [67] using a three-layered self-organizing multi-agent system in which agents are in charge of cloud participants and resources and which addresses dynamic contracting under incomplete information.

Another approach that tackles service collaboration in cloud computing is presented in [68], where a multi-agent system is used in conjunction with “a negotiation mechanism (mean algorithm and protocol) that allows nodes in a ‘cloud’ to achieve an effective collaboration among service providers”.

From the data perspective, cloud governance must facilitate privacy and security while providing data integrity for the information it holds. It must store complete information related to the cloud applications it services from service descriptions to run-time monitoring information used for audit.

Multi-agent approaches in the field cloud data storage typical focus on providing data integrity services, such as the solution presented in [69] called ‘CloudZone ’ where a multi-agent architecture is in charge of providing integrity through the use of two types of agents, one which provides a user interface for the client and one in charge of data integrity and reconstruction by performing regular data backup.

A specific approach shows how data warehouses can be deployed in the cloud environment using a multi-agent system designed around Web services in order to benefit from the core cloud characteristics while maintaining traditional data warehouse benefits [70].

In regard to the security concerns of cloud storage solutions, Talib et al. [71] propose a multi-agent based security framework built on top of Java Agent Development (JADE) for managing the security of cloud data storage in order to guarantee data correctness, integrity, confidentially and availability [71].

Tackling privacy and security, Angin et al. propose an identity management solution for cloud computing, a prototype being developed using mobile JADE agents, which has “entity-centric mechanism for protecting privacy of sensitive data throughout their entire lifecycle […] known as the active bundle scheme […] is able to provide users with control over their data, allowing them to decide what and when data will be shared” [72].

6 Conclusions

Current advancements have made cloud computing into a thriving market where enterprises of all sizes are fighting for their share, to take advantage of the business models it brings and of its core characteristics.

Unfortunately, since its inception, many problems have plagued this new paradigm and so it has become an active research topic for many communities worldwide. This has also constituted a strong deterrent for many enterprises which are reluctant to adopt it in fear of losing control over their data, over the services and applications they provide for their clients.

While some of its core problems like cross cloud development and interoperability are or have already been addressed through PaaS or cloud management solutions, problems that are related to the business layer or the support for cloud service lifecycle are yet or insufficiently addressed.

This chapter has provided a comprehensive overview of cloud management and cloud governance detailing interactions between them, showing how one complements the other, and emphasizing the role they play in general cloud adoption. In addition, many solutions that address the whole picture or just a partial one are analyzed, especially solutions which involve multi-agent systems.