Analyze Growth Trends and Forecast Future Requirements

Print

Cloud Service Selection

By Smrati Gupta, Peter Matthews, Victor Muntes-Muléro, and

Jacek Dominiak

Selecting Services for Agile Application Development

In the application economy, digital business initiatives are the

forefront of the growth strategy of many companies. Cloud-

based solutions offer a competitive advantage for both large

companies and micro-, small-, and medium-sized enterprises

(SMEs), and this has led to a rapid increase in the number of

cloud service providers (CSPs). CSPs aim to improve consumers'

experience through digital platforms that allow users to access

data and services from any location and through multiple

channels with assured performance and availability. This is

usually studied from a single provider perspective, ignoring the

growing number of multicloud applications that use different

cloud services from different cloud service providers.

Beyond the usual cloud services and providers, the interest in

the Internet of things (IoT) and fog computing is quickly growing

as those technologies are seen as an opportunity for innovative

new services. With the increase in components and applications

in modern systems, the complexity of software systems

implemented in multicloud environments increases. Making

decisions in the new era of multicloud applications becomes one

of the next challenges.

Software companies need to quickly move through innovation

cycles to be competitive. Using continuous delivery approaches

becomes essential, increasing the need for agile decisions. Like

many other IT platforms, multicloud applications face important

challenges related to security, availability, performance,

compliance, integration, purchasing, automation, and insight.

Selecting the best cloud service for a particular application

requires an understanding of application requirements as well as

the interoperability between this specific service and other

services offered by other CSPs used by the application. This

decision may have an effect not only on the performance and

user experience of the application but also the business

support.

The best service selection depends on multiple criteria including

cost, risk, and quality. Continuous delivery models require

involving different stakeholders in the system, providing

complementary perspectives, including business decision

makers, architects, and systems operators.

One of the challenges is to find an efficient mechanism that

allows translating these requirements into measurable metrics

that make it possible to evaluate the fitness of a particular set of

cloud services and providers for a particular application. We will

discuss the use of a decision support system (DSS) for cloud

service selection. In this reading, we discuss the main challenges

related to DSSs and present the tools implemented for this

purpose. We also discuss the evolution of these DSSs in the

future and consider next steps.

Decision Support Systems for Cloud Service Selection

Developing a recommendation system for selecting a cloud

service is an interesting challenge from both a conceptual and a

technical point of view. In this section, we highlight the

challenges required for a generic DSS that assists the cloud

service selection process from the heterogeneous nature of

services in a multicloud environment.

Cloud Service Selection for Continuous Delivery

Continuous delivery is a goal for IT departments. Creating the

kind of apps used on a smartphone has driven a change from

the traditional waterfall method of development to the agile

strategy. Agile development has moved the application

deployment bottleneck from development to operations, and

DevOps is a process that will remove the bottleneck to

continuous delivery. This process delivers apps that are

constantly refreshed with new features and fixes at a decreased

cost. Delivering new applications requires speed and flexibility

and is facilitated by creating applications from cloud services.

Composing services into new applications reduces the amount

of new developed code that needs to be written. The challenge

is to select services that match the required functionality without

sacrificing performance and availability.

Risk Analysis for Cloud Service Selection in Multiclouds

A DSS for cloud service selection requires a systematic

mechanism that allows the translation of the requirements of the

naïve users into tangible properties of the cloud services that

need to be assessed while making a selection. Furthermore, the

mechanism needs to ensure quality guarantees for the end

users. Risk analysis provides a solution for development of such

a mechanism. Risks pose a problem in selecting and adopting

appropriate cloud services. Consequently, identification,

definition, and quantification of these risks are important

considerations in DSS development.

Another advantage of adopting risk-based analysis in decision

support design for cloud service selection is the integration of

multiple stakeholders into the decision-making process. Risk

analysis provides a concrete method of translating the

requirements from multiple stakeholders into the properties of

cloud services in the desired domains.

Risk-based analysis provides a mechanism to systematically

analyze the quality of cloud services by assessing the risks they

impose on the critical domains as well as the cloud service

properties that can mitigate those risks, underpinning the

satisfaction of quality requirements.

The first step in risk-based analysis involves identifying risks in

cloud service selection. A common method is to allow the users

to present their requirements in terms of the assets they intend

to protect. Assets can be described as business-oriented or

technical, tangible or intangible, etc. The risks that the user

entails by "cloudifying" its assets can be then be systematically

determined. Some typical risks in multiple cloud domains are:

 unauthorized access from the IaaS provider

 insufficient isolation

 insufficient physical security

 data exposure to government authorities

 increase of infrastructure prices

 expensive support services

 change of price models

 storage system corruption

Desirable cloud services have properties that ensure mitigation

of those risks. For example, mitigating properties can include

the existence of sufficient support services, data location in

desirable geographical boundaries, sufficient certifications from

the cloud service providers, or financial stability conditions. The

risk-based analysis provides a map of user requirements defined

as assets into desirable cloud properties described as

treatments within a DSS.

There are additional risks associated with multicloud

environment service selection:

 vendor lock-in

 complex data migration

 interoperability

 security breaches

 cost unpredictability

These risks require additional properties to be satisfied in order

to mitigate them. These properties are not essentially associated

with the cloud service, but with the interaction between the

services. For example, since a user may select services from

different providers, that user faces the risk of interoperability

between the services—due to compatibility issues, service-level

agreement issues, or simple change in price models of a certain

service leveraging effect on other services. Such risks are

mitigated by imposing constraints on the selection of a set of

services rather than a single service.

Risk-based analysis provides a means of communicating user

requirements in a DSS development. It also provides a

mechanism for quality assessment and identification of

comparative domains among the different services in single

cloud and multicloud environments.

Cloud Service Description Standardization

The standardization activity relating to service description has

been patchy and incomplete. A form of service description using

common data types and structures is a precursor to service

matchmaking decisions. There have been a variety of service

descriptions and standardization efforts over the years, but few,

if any, have had any lasting impact.

One of these efforts that had initial promise was the Service

Measurement Index (SMI) (Siegel & Perdue, 2012). SMI was an

initiative started by CA Technologies and later adopted by

Carnegie Mellon University, which managed the Cloud Services

Measurement Index Consortium (CSMIC) (Adobe Spark, n.d.).

SMI was based on a theory of "relative goodness" that was used

to circumvent the more accurate but complex semantic solutions

for comparison. SMI was finally abandoned when filling even a

small portion of the database for describing services proved

problematic.

An approach taken by MODAClouds (Model-Driven Approach for

Design and Execution of Application on Multiple Clouds) has

been to use data that provides constraints or functional and

nonfunctional requirements and pragmatically evaluating that

data based on the method of gathering and the availability of

the data. The MODAClouds project leaders felt that there was

little point in mandating a metric that could not be gathered, or

one that relied on the goodwill and compliance of a wide

number of cloud solution providers (CSPs). Data acquisition is an

ongoing limitation to the description and comparison of cloud

services.

Data Gathering in Multicloud Environments

The quality of recommendations made by the DSS is dependent

on the quality of data used for cloud services comparison.

Quality data enhances the possibility of meeting requirements of

the users more closely, but it also provides the users more

dimensions in which to compare the cloud services. Data

gathering for comparison has a number of obstacles:

 Lack of interest or business value: CSPs are the primary

source of data about the cloud services. Small CSPs may

enter data into a DSS database as a potential dissemination

strategy. Larger CSPs such as Amazon have no incentive to

provide comparison data and expressly exclude the

possibility in their terms and conditions.

 Legal issues and accuracy from third-party portals: There

are multiple analytic portals (e.g., CloudHarmony, Cloudy

Metrics) that provide a comparative analysis of cloud

services. Data from these websites can be accessed through

application programming interfaces or simple parsing.

However, this incurs a risk of data accuracy being

dependent on a third party. Legal constraints such as

copyright and terms and conditions may also prevent the

use of third-party data.

 Crowdsourced data quality: Crowdsourcing is another

mechanism to gather cloud services data. Data provision by

individuals is subject to the same accuracy and subjective

opinions as travel recommendation and review sites.

 Procurement complexity: Parsed data may not follow any

commonly known structure. The most valuable data for

comparison purposes is often described in freehand

fashion such as reviews or articles.

 Lack of standards: Another example of the problem within

the data gathering process is lack of a clear JSON-based

standard or lack of validating structure, which is the base

of XML.

Data gathering is an integral component to decision support,

and the module must provide a mechanism to automatically

gather and update data ensuring its accuracy and currency.

Coping with Complexity in SaaS

An important consideration in the development of a DSS is the

clear identification of the paradigms of comparison among the

different cloud services. Risk-based analysis provides a

systematic procedure for defining the requirements for cloud

services, but it still creates a challenge to build a clear paradigm

of comparison for software as a service (SaaS). Infrastructure as

a service (IaaS) and platform as a service (PaaS) domains are

more simple due to the objective nature of paradigms

(comparison based on technical specifications, on nature of

platforms, etc.).

SaaS domains imply a higher user interaction, thereby providing

a more abstract quantification of paradigms to compare with. In

addition, the types of SaaS are varied and lack any

benchmarking and standardization. Therefore, for a DSS

development, it is complicated to provide a recommendation for

an SaaS domain. It is important to account for this complexity in

the design of a multicloud DSS.

Decision Support Tools for Cloud Service Selection

In order to address the challenges outlined in the previous

section, the MODAClouds DSS was developed as a generic

recommendation system to provide help with cloud service

selection, taking into account the multicloud environment and

heterogeneous domains of the services. The DSS prototype is

based on a risk analysis-based requirement generation, allowing

multiple stakeholder participation along with inherent data

gathering mechanisms. It provides recommendations by solving

the multicriteria decision-making problem. In this section, we

outline the conceptual backbone forming the DSS.

DSS is made up of three main processes: data gathering and

evaluation from the end user, data gathering and evaluation

from the cloud service providers, and service matchmaking (see

figure below).

Basic Building Blocks of DSS

The primary step is to assimilate data from end users and

process it in order to identify end-user requirements. In

addition, there is a requirement to gather the data about the

cloud services and their providers (directly or using third-party

services, e.g., websites that provide comparative analysis of a

cloud service provider), and evaluate that data. Finally, there is a

need for service matchmaking, where the processed data from

cloud service providers is fine-tuned or operated upon by the

end-user requirements to generate appropriate solutions.

A major challenge identified in the decision-making process is

the specification of the requirements from the end user. To

overcome this challenge, the proposed DSS helps users specify

their requirements by enabling them to define the assets-risk-

treatments. The end user can be the business decision maker,

the technical system architect, and the risk analyst and

requirements engineer in an enterprise.

End users are required to specify assets that they intend to

protect. These assets can be intangible or tangible. Intangible

assets are further subdivided as business-oriented or technical-

oriented assets. Typical examples of business-oriented

intangible assets (BSOIA) include customer loyalty, product

innovation, and sales rate. Similarly, typical examples of

technical-oriented intangible assets (TOIA) include data

integrity, service availability, and end user performance.

Furthermore, the system architect is also allowed to specify the

tangible assets that must be protected in order to protect the

business- and technical-oriented intangible assets. The tangible

assets describe the architectural elements intended to be

externalized using the cloud services. Typical examples of such

assets includes server (IaaS), database (PaaS), middleware (SaaS),

etc. Along with this specification, the end user is expected to

supply the "importance" of an asset on a risk acceptability scale,

which identifies how much risk a tangible asset can endure.

Each of the assets supplied by the end user is susceptible to

certain risks. Therefore, the DSS allows the users to map the

possible risks from which the asset needs to be protected. The

identification of these risks per asset is a progressive learning

process. The risks associated with different assets are identified

with each use of the DSS, and are stored in the database. As the

number of DSS users increases, the association of assets to risks

becomes richer and more concrete.

Identifying the risks per asset, the user also identifies the

likelihood and consequence of each risk, communicating the

impact that is associated with each risk on the asset to the DSS.

The scales of expressing these quantities are:

 Likelihood: rare (1), unlikely (2), possible (3), likely (4),

certain (5)

 Consequence: insignificant (1), minor (2), moderate (3),

major (4), catastrophic (5)

A joint function quantifies the risk from the inputs above. This

function is highly flexible in nature: it may be discrete or

continuous, variable or constant. An example of this function is

the use of a composite risk index, defined as a product of

likelihood and consequence value. For each asset, a risk

acceptance function specifies how much risk likelihood and

consequence is acceptable for that asset. Furthermore, when the

user specifies the associated risks along with the likelihood and

consequence of each of the risk, the acceptability of risk is

based on the predefined acceptable risk levels for each asset.

Should the risk be acceptable, the treatment is not required.

However, if the risk is unacceptable, treatment is required to

mitigate the risk. Hence, for all the risks to be mitigated, the

treatments are required. These treatments serve as

requirements for the cloud services that the user desires. Typical

examples of treatments are data location guaranteed in certain

geographical region, availability of customer support, and

guarantees of the provider's financial stability.

Based on the treatments, the required properties of the cloud

services are identified. The data-gathering module in DSS

evaluates the cloud services on the basis of the user-identified

treatments. The DSS then performs service matchmaking. This

process involves providing an aggregate score on the basis of all

the treatments chosen by the user and a grading of the cloud

services. The closest match to the user requirements forms the

most eligible recommendation. In the next section, we provide

the technical implementation of these concepts for the

development of DSS.

Technical Challenges and Implementation

Overview of Technology Supporting DSS

Implementation of the DSS design within the scope of

MODAClouds has been developed considering future data set

needs and with the assumption that the data set needs to be

easily exportable and adaptable to the nature of the domain that

it is exploring. Taking that into account, the core of the data

storage is modeled around the graph-capable database

ArangoDB. ArangoDB is a free and open-source database with a

flexible data model for documents, graphs, and key values

(ArangoDB, n.d.).

For the DSS, documents and graph capabilities of the database

are most frequently used. The user interface is developed as a

single page web application in JavaScript with technologies such

as AngularJS, used for all the user interactions and user

feedback mechanisms, and NodeJS, which is used for XML

validation against XSD plus additional end points to automate

the collection of data from other parts of the project. DSS main

automatic data collection modules are designed as standalone

tools written in Scala programming language. All the modules

developed for the data collection can be easily extended or

embedded as libraries in the existing application to be adapted

to the specific data-gathering process needs.

User Data Gathering Implementation

A set of coherent user interface elements have been used,

including standard and enhanced selections mechanisms. This

will gather the requirements in an organized, comprehensible

fashion and accommodate the fact that the selection

requirements are incremental sets specified by the multiple

actors.

The primary selection tool is a searchable single selection list

box. The list is populated based on the previous steps or the

internally specified connections. The select menu is presented

across all the selection steps. Other techniques such as a slider

represent the data type with predefined ranges. The slider allows

the user to see all the ranges at once and gives direct visual

feedback on scale construction.

The process by itself is constructed as a six-step wizard that

allows the user to see the current context across the full

selection.

Cloud Services Data Gathering Implementation

The automatic data gathering process of the decision support

tool is composed of two main modules: data import and data

save. Those modules are designed to work as a part of the

application as well as the standalone modules. The data import

module is responsible for the data extraction and data

transformation from the structured data sources. The module is

able to consume the structured data from the flat file local data

sources in JSON, XML, and XLSX formats and respective over the

network representations of such structures, such as REST,

ODATA, and WSDL HTTP end points. The output of this module

is JSON, which can be invoked as an input for the data saved

module. The data save module is designed to consume a

predefined modeled JSON input in order to represent and build

graph-based data structures used by the process service

matchmaking based on the user-specified requirements. This

module is able to build up or enrich the data set based on the

data specification.

 Sharing process: In order to enable optimal requirement

selection, the DSS allows multiple actors to participate

during the definition of the set of requirements the service

needs to provide. This approach for data gathering ensured

the development of the selection sharing process. It allows

an actor to save the current set of selected assets, risks,

and treatments along with the selected values and

representation selection. The export file allows the user to

share the fulfilled selection with other actors using the

preferred sharing medium. Multiple sets of predefined

selections can be saved and shared to more closely

targeted parts of the process to the appropriate actor.

 Visualization: The DSS has been equipped with multiple

data visualizations in order to simplify the overview and

understanding of the user process, the mechanisms of

understanding the selection criteria interaction, and data

connections.

 Multicloud-specific features: The DSS also supports the

mitigation of risks particular to the multicloud environment

by assessing the risks related to the selection of a group of

services. For example, the DSS warns users in the case of a

vendor lock-in in a selection of services by evaluating the

providers for all the services in the selection. The DSS also

provides an evaluation of migration out of any service by

assessing the dimensions that support migration

capabilities in a service. These properties provide a holistic

vision of the solution matched to a multicloud environment.

Evolution of Cloud Services, Decision Support, and Future

Work

This reading discusses the use of a DSS to simplify the choice of

services that match functional and nonfunctional requirements.

This DSS uniquely uses risk management techniques to

complement the requirements used to deliver a qualified list of

services for composition. Some of the decision criteria are

subjective, and the use of decision support to simplify choices

removes the need for service choices based on multifactor

optimized expert systems. Cloud services are evolving into a

wider architectural movement that includes containers and

microservices. Cloud services used in a multicloud environment

linked with microservices and container APIs lead to a

multiservice style of architecture, building applications based on

component-oriented development. This is more suitable to agile

and DevOps development, mapping services to agile user stories

and components.

The number of internal and external services available for

developers is already increasing, and there will be a need to

identify, classify, and describe services in a common way to

remove redundancy and improve development times. This

evolution demands service description, discovery, and

matchmaking capabilities that can benefit from decision support

of the type described in this reading. Data gathering remains a

legally and technically difficult area, potentially preventing all

but the most simplistic of services choices being made. This is

an area of future investigation, possibly in collaboration with

some of the cloud standardization initiatives and organizations

such as the Cloud Security Alliance and Cloud Industry Forum.

References

Adobe Spark. (n.d.). Selecting a cloud provider. Retrieved from

https://spark.adobe.com/page/PN39b/

ArangoDB. (n.d.). Why ArangoDB? Retrieved from

https://www.arangodb.com/why-arangodb/

Siegel, J., & Perdue, J. (2012). Cloud services measures for global

use: The service measurement index (SMI). In 2012 Annual SRRI

global conference, Carnegie Mellon University. Mountain View,

CA.

Licenses and Attributions

Chapter 2: Cloud Service Offer Selection by Gupta et al.

from Model-Driven Development and Operation of Multi-Cloud

Applications is available under a Creative Commons Attribution

4.0 International license. © 2017, The Authors. UMGC has

modified this work and it is available under the original license.