Project topics and materials
Get Complete Project Material File(s) Now! »
Essential Characteristics
The NIST definition of Cloud Computing [1] identifies five essential characteristics of cloud computing: On-demand self-service resource provisioning refers to the ability to provision or release computing resources such as computing power, storage and networking without the need of human interaction between the cloud customers and providers. This implies that cloud providers should offer means for managing computing resources through programmable interfaces. Broad network access implies that cloud computing resources are made available through standard networking protocols and can be accessed through the Internet. Resource pooling. Resources are provisioned to cloud consumers from a pool of shared resources managed by the cloud provider. The consumer has no control over the exact location of the resources and it is up to the provider to decide in which virtual or physical machine it is better to provision customers resources. Still, consumers can specify higher-level location constraints such as the data center or availability zone in which the resources are to be provisioned. Elasticity refers to the ability to rapidly provision or release resources to scale the system according to consumer demand. Measured services. Resource utilization is monitored, controlled and recorded to inform both providers and consumers about the resource utilization. This information can be used by providers and consumers to optimize their resource usage and allocation strategy and to charge users according to their utilization of resources.
Service Models
Computing resources in cloud computing are delivered as services at varying levels of abstraction that define the degree of control that consumers have over computational resources. Service delivery is often categorized into three different models: Infrastructure as a Service (IaaS). Infrastructure services provide direct access for con-sumers to low-level computing resources such as storage, networking and computing nodes, often provided as virtual machines. Consumers do not have direct access to the physical machines and may have limited control over networking components. Still, they have complete control over all software stack from the operating system level up to the application level. Platform as a Service (PaaS). Platform services provide a runtime environment for directly deploying applications. These services are often specialized and conceived to support a given programming language, platform, technology or ecosystem. A platform will often provide a runtime environment such as an application server together with a set of libraries and associated tools. Consumers do not need to manage or have limited control over the underlying infrastructure such as cloud servers, networking and storage. Additional services that are used in the implementation of applications, such as database management systems, are also often included in this category. Software as a Service (SaaS). Software services provide application functionality to cloud consumers. Applications are made available through a user interface such as a web page or a thin client; or by means of an application programming interface. Consumers do not manage or control infrastructure resources or development platforms and only have access to application specific configuration options.
Though this taxonomy of service models provides a useful classification for cloud services, there is not a hard line that separates service models, and some cloud services may exhibit properties of more than one service model. For example, some database services do not provide means for managing their resources and consumers are charged in terms of application specific concepts such as the number of rows stored and database queries rather than the underlying resource usage. These properties would qualify these services as a SaaS offering. Still, these services are mostly used by developers to store their application data and could also be regarded as platform services. Besides this, cloud providers may deliver services at multiple service models and higher-level cloud services may be built on the top of lower-level cloud services. In addition to these three basic service models, we can find throughout the cloud computing landscape a large number of other models such as Database as a Service (DaaS), Storage as a Service (SaaS), Network as a Service (NaaS), Analytics as a Service (AaaS), etc. These service models, which are often grouped under the umbrella term of Everything as a Service (XaaS), can be considered as specializations of the three previously described service models.
Deployment Models
The NIST definition [1] of cloud computing also specifies four deployment models. The deployment models determinate how the cloud infrastructure is operated and which consumers have access to it. In a private cloud, the infrastructure is provisioned to be exclusively used by a single organization. It can be directly managed by the consumer organization or by a third-party. In a community cloud, many organizations may join to provision the infrastructure of a cloud that will be used exclusively by the organizations in the community. As in the case of private clouds it can be managed directly by members of the community or by a third-party provider. A public cloud is one in which the cloud resources are available for the general public over the Internet upon the payment of the service fees. A hybrid cloud integrates two or more clouds in any of the other models in a way that supports data and application portability across the consistuent clouds.
Configuration and Management
of Multi-Cloud Systems
Since the advent of cloud computing, several concerns have been raised concerning about the dependence of cloud consumers on providers and the security of cloud computing environments. These concerns led to a profusion of approaches that propose different means for consuming resources from multiple clouds such as hybrid clouds, federation of clouds, inter-cloud computing, multi-cloud computing, etc. In this section, we present an overview of the aspects involved in the consumption of resources from multiple clouds and a survey of existing approaches for multi-cloud computing.
Consuming Resources from Multiple Clouds
Previous works in the literature [7–9] have been dedicated to the study and classification of approaches for the use of multiple clouds. Here, we give an overview of these classifications about the motivation for using multiple clouds and the approaches for consuming resources from multiple clouds.
Motivation for using multiple clouds
In [8], Petcu presents a list of the top 10 reasons for consuming resources from multiple clouds. In [7], authors summarizes the benefits of using multiple clouds into 3 categories, while Toosi et al. [9] identifies 6 key benefits that capture the essential motivations for cloud interoperability. We classify these identified motivations, listed in Table 2.1, into three broad categories: Reducing vendor dependence. This includes the uses of multiple clouds to avoid lock-in to a provider specific technology and to implement mechanisms for redundancy and disaster recovery thus improving the system resilience to cloud failures. Complying with constraints, requirements and service offerings. Multiple clouds may be used to comply with legal issues, regulations and internal policies that require some services or data to be deployed in data centers located in a given region or within a private cloud. They can also be used when a single cloud does not provides all the services required by the system. Improving performance, quality of service or resource utilization. As different providers may offer different advantages in using specific features, combining them can be useful to improve quality of services or optimize costs. Distributing services closer to clouds that are closer to their end users may be used to reduce the overall latency. Multiple clouds can also be used to offload processing to other clouds when dealing with request peaks.
Approaches for Configuration and Managementof Multi-Cloud Systems
As we saw above, several approaches have been proposed to support the consumption of resources from multiple clouds. In this work we analyze only the multi-cloud approaches, in which the integration is driven by cloud consumers. Besides this, we focus on approaches that deal with aspects related to the configuration and management of multi-cloud systems. During this analysis, we identify how these approaches deal with the selection of cloud providers and services and particularly how they deal with the heterogeneity and variability of cloud environments.
PaaSage
PaaSage [36–42] is a platform to support the design and deployment of multi-cloud applications based on model-driven engineering principles. In PaaSage, users design provider-independent deployment model that defines application components and their requirements. Components may include location, service level objectives, scalability and optimization requirements. These requirements are matched against cloud provider offerings to obtain a provider-specific model. The CAMEL [42] modeling language allows for defining concepts such as locations, metrics, resource types and capabilities that can then be used both in providers and requirements definitions. Variability management is based on the Saloon approach [26].
MODAClouds
The goal of the MODAClouds [43, 37, 44, 45, 20] project was to provide methods and tools for the design and automatic deployment of multi-cloud applications. The MODAClouds project was developed alongside PaaSage and share some common contributions and similarities. It also employs a component-based model for applications and a separation between provider-independent and provider-specific models. Provider-independent models define an assignment from application components to cloud services while provider-specific models define the exact cloud services and providers. It also employs a modeling language, called CloudML [45], which supports definition of unifying concepts across provider offerings. MODAClouds distinguishes from PaaSage by providing an approach based on risk analysis to support cloud services selection and the use of mechanisms for performance prediction and optimization. The project also includes a mechanism for runtime monitoring and adaptation based on Models@Run.time [28, 46, 13, 47, 48]. Variability in providers’ configuration is not taken into account during the selection or configuration of cloud services.
Variability in Infrastructure Resources Configuration
Another range of approaches have been proposed to manage the variability in the configuration of infrastructure resources or services. For instance, [92, 93] use variability models to define how software packages (e.g. operating system, databases, application servers, frameworks, etc) can be combined to build a Virtual Machine Image (VMI) that can be later used to instantiate a virtual machine. Meanwhile, other works [25, 71, 94, 23] also manage the variability in the configuration of infrastructure services such as virtual machine size, data center location, storage type, etc. Different from the previous category, in these approaches the goal is not build a product-line of cloud applications, but to manage the variability in the way infrastructure resources can be configured. These works employ variability management to achieve different goals such as optimizing power consumption and performance by finding optimal configurations; or simplifying the provisioning of resources and deployment of applications to the cloud.
Variability in Cloud Services Configuration
In this third category of approaches [24, 26], variability management is employed to select and configure cloud services or providers that support some requirements and generate the corresponding configurations. Feature models are used to capture the variability in the configuration of cloud services or providers, while requirements are defined using provider-independent concepts. Requirements are evaluated against feature models for different cloud services or providers in order to find complying services or providers and generate a configuration. While in [24] the variability is defined on a per-service basis, in [26] variability defines the options available in a cloud provider for deploying an application.
Table of contents :
List of figures
List of tables
1 Introduction
1.1 Motivation and Scope
1.2 Objectives
1.3 Contributions
1.4 Publications
1.5 Dissertation Outline
I State of the Art
2 Configuration and Management of Multi-Cloud Systems
2.1 Cloud Computing
2.1.1 Essential Characteristics
2.1.2 Service Models
2.1.3 Deployment Models
2.2 Configuration and Management of Multi-Cloud Systems
2.2.1 Consuming Resources from Multiple Clouds
2.2.2 Approaches for Configuration and Management of Multi-Cloud Systems
2.2.3 Discussion
2.3 Variability Management in Cloud Computing
2.3.1 Variability in Cloud Applications
2.3.2 Variability in Infrastructure Resources Configuration
2.3.3 Variability in Cloud Services Configuration
2.3.4 Discussion
2.4 Summary
3 Software Product Lines
3.1 Software Product Lines Engineering
3.1.1 Variability
3.1.2 Software Product Line Engineering Process
3.2 Feature Models
3.2.1 Feature Diagrams
3.2.2 Analysis Operations
3.2.3 Cardinality-Based Feature Models
3.3 Dynamic Software Product Lines
3.3.1 Contextual Variability
3.3.2 Variability Modeling in DSPLs
3.3.3 Dynamic Variability Mechanisms
3.3.4 Adaptation in DSPLs
3.4 Summary
II Contributions
4 Feature Models and Relative Cardinalities
4.1 Motivation
4.1.1 Motivating Example
4.1.2 Challenges
4.2 Relative Feature Cardinalities
4.2.1 Formalization
4.2.2 Cardinalities Consistency
4.2.3 Relative Cardinalities and Additional Constraints
4.3 Automated Analysis of Relative Cardinalities
4.3.1 Feature Modeling with Relative Cardinalities
4.3.2 Cardinalities Consistency
4.3.3 Configuration Checking
4.3.4 Partial Configuration Checking
4.4 Discussion
4.5 Summary
5 Feature Models and Temporal Constraints
5.1 Motivation
5.1.1 Motivating Example
5.1.2 Challenges
5.2 Variability Modeling with Temporal Constraints
5.2.1 Preliminary Definitions
5.2.2 Temporal Constraints
5.2.3 Reconfiguration Operations
5.3 Automated Analysis of Temporal Constraints
5.3.1 Reconfiguration Query
5.3.2 Symbolic Representation
5.4 Cardinality-Based Feature Models: the Case of Cloud Computing
5.4.1 Context Feature and Constraining Expressions
5.4.2 Analysis of Temporal Constraints
5.5 Discussion
5.6 Summary
6 Automated Setup and Adaptation of Multi-Cloud Environments
6.1 Motivation
6.1.1 Motivating Example
6.1.2 Challenges
6.2 Overview
6.3 A Domain-Specific Modeling Language for Multi-Cloud Environment Requirements
6.4 Mapping Requirements to Cloud Services
6.4.1 Cloud Provider Service Definition
6.4.2 Mapping Service Requirements to Feature Selections
6.5 From Requirements to Configuration of a Multi-Cloud Environment
6.6 Adaptation of Multi-Cloud Environments
6.7 Discussion
6.8 Summary
III Evaluation
7 Evaluation
7.1 Implementation details
7.1.1 Modeling
7.1.2 Reasoning
7.2 Experiments and Evaluation
7.2.1 Feature Models with Relative Cardinalities
7.2.2 Feature Models with Temporal Constraints
7.2.3 Setup and Adaptation of a Multi-Cloud Environment
7.3 Discussion
7.4 Summary
IV Final Remarks
8 Conclusions
8.1 Contribution Summary
8.2 Perspectives
References
