2. Cloud Service Offer Selection

In the application economy, digital business initiatives are at the forefront of the growth strategy of many companies. Cloud based solutions offer a significant competitive advantage for both large companies and SMEs, leading to a rapid increase in the number of Cloud Service Providers (CSP). An important CSP driver is the improvement of 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 multi-Cloud 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 growing very fast as it is seen as an opportunity to launch innovative new services in the very near future. With the market growth and the increase in the number of components and applications in modern systems, the complexity of software systems implemented in multi-Cloud environments increases exponentially. Making decisions in the new era of multi-Cloud applications becomes one of the next challenges. Software companies need to work through fast innovation cycles to be competitive in a changing and dynamic market. Following continuous delivery approaches becomes essential, increasing the need for agile decisions. Analogous to many other IT platforms, multi-Cloud applications (see Part IV) 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, and the interoperability between this specific service and other services offered by other CSP used by the application. This decision may have an important impact not only on the performance and user experience of the application and through them the business support. As the role of the CIO becomes that of an orchestrator of these increasingly complex systems, decisions do not depend anymore on a single dimension or a single person. The best service selection depends on multiple criteria including at least cost, risk and quality. Fast iterations in continuous delivery models require involving different stakeholders in the system, providing complementary perspectives, including for instance business decision makers, architects and systems operators. One of the main 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. In this chapter, we discuss Decision Support Systems (DSS) for Cloud service selection. We discuss the main challenges related to DSS and present the tools implemented for this purpose. Afterward, we discuss the evolution of these DSS in the future and discuss next steps.

The development of a recommendation system to assist the Cloud service selection is an interesting challenge from both conceptual and technical point of view. In this section, we highlight the major challenges that are required to be addressed in development of a generic decision support system that assists the Cloud service selection process from heterogeneous nature of services in Multi-Cloud environment.

Continuous delivery is a frequently mentioned goal for IT departments. The emergence of apps on a smart phone has driven a move from the traditional waterfall method of development to the agile development 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 has been shown to deliver apps that are constantly refreshed with new features and fixes at a decreased cost and higher velocity. Delivering new applications requires speed and flexibility and is facilitated by creating applications from components such as Cloud services. Composing services into new applications reduces the amount of new developed code that needs to be written. As such there is little to check into a configuration and source code management environment beyond the links to services and workflow. The challenge is in selection of services that match the functionality required without sacrifice of performance and availability.

A decision support system for Cloud service selection requires a systematic mechanism to allow 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 provision of quality guarantees as desired by the end users. Risk Analysis provides a solution for development of such a mechanism. The existence of relevant risks poses a complex problem in selection and adoption of appropriate Cloud services. Consequently, identification, definition and quantification of these risks are important considerations in decision support system 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 involved in the decision making process 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 and the Cloud service properties that can mitigate those risks, underpinning the satisfaction of quality requirements.

The first step in risk based analysis involves identification of risks in Cloud service selection. A common method of identifying risks 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:

Risks can be mitigated by using Cloud services that have properties that ensure mitigation of those risks. For example, mitigating properties can be the existence of sufficient support services, data location in desirable geographical boundaries, sufficient certifications from the Cloud service providers, financial stability conditions, etc. In general, these properties are treatments for risks such that they ensure mitigation. The risk based analysis provides a mapping of user requirements defined as assets into desirable Cloud properties described as treatments within a decision support system.

There are additional risks associated with multi-Cloud environment service selection. Such risks can include vendor lock-in, complex data migration, interoperability, security breaches, cost unpredictability etc. These risks require some 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, as a user may select services from different providers, he faces the risk of the interoperability between the services due to compatibility issues, SLA issues, or simple change in price models of a certain service leveraging affect 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 decision support system development. It also provides a mechanism for quality assessment and identification of comparative domains among the different services in single Cloud and multi-Cloud environment.

The standardisation activity relating to service description has been very 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 standardisation efforts over the years but few, it any have had any lasting impact.

One of these efforts that had initial promise was the Service Measurement Index (SMI) [1]. SMI was an initiative started by CA Technologies and later adopted by Carnegie Mellon University who managed the Cloud Services Measurement Index Consortium (CSMIC).¹ SMI was based on a theory of “relative goodness” which 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 problematical. The approach taken by MODAClouds has been to use data that provides constraints or functional and non-functional requirements and pragmatically evaluating that data for gathering based on the method of gathering and the availability of the data. The MODAClouds project felt that there was little point in mandating a metric that could not be gathered or relied on the good will and compliance of a wide number of CSPs. Data acquisition is an on-going limitation to the description and comparison of Cloud services.

The quality of recommendations made by the DSS is heavily dependent on the quality of data used for comparison of Cloud services. Quality data enhances the possibility of meeting requirements of the users more closely, but also provides the users more dimensions to compare the Cloud services in. Data gathering for comparison has a number of obstacles:

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.

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 still creates a challenge to build a clear paradigm of comparison for Software as a Service (SaaS). IaaS and PaaS domains are more simple due to the objective nature of paradigms (comparison based on technical specifications, based on nature of platforms etc.). SaaS domains implies a higher user interaction thereby providing a more abstract quantification of paradigms to compare them with. In addition, the types of SaaS is highly varied and lacks any bench-marking and standardization. Therefore, for a DSS development, it is highly complex to provide recommendation for SaaS domain. It is crucial to take into account this complexity for the design of a multi-Cloud DSS.

In order to address the challenges outlined in the previous section, the MODAClouds DSS was developed as a generic recommendation system that provides assistance in Cloud service selection taking into account the multi-Cloud 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 and provides recommendations by solving the multi-criteria decision making problem. In this section, we outline the conceptual backbone forming the DSS.

The basic building blocks of DSS are comprised of three main processes: first, data gathering and evaluation from the end user; second, data gathering and evaluation from the Cloud service providers, and third, service matchmaking (see Fig. 2.1). 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 which provide comparative analysis of Cloud service provider), and evaluate it. 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 assists users in specifying their requirements by enabling them to define the assets-risk-treatments. The end user can be the business decision maker, technical system architect, 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, sales rate, etc. Similarly, typical examples of technical oriented intangible assets (TOIA) include data integrity, service availability, end user performance, etc. Furthermore, the system architect is also allowed to specify the tangible assets which require to be protected in order to protect the business and technical oriented intangible assets. The tangible assets describe the architectural elements that are 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 can a tangible asset 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:

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 value. An example of this function is the use of composite risk index, which is 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 pre-defined 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 which the user desires. Typical examples of treatments are data location guaranteed in certain geographical region, availability of customer support, guarantees of provider’s financial stability etc.

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 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.

Implementation of the decision support system design within the scope of the MODAClouds has been developed taking into consideration future data set needs and with assumption that the data set needs to be easily exportable and adaptable to the ever changing nature of the domain which it is exploring. Taking that into account, the core of the data storage is modeled around the graph capable open source database called ArangoDB.² ArangoDB is a distributed free and open-source database with flexible data model for documents, graphs, and key-values. 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 like AngularJS, used for all the user interactions and user feedback mechanisms and NodeJS which 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 a 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.

A set of coherent UI 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, at times with legend. 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.

The automatic data gathering process of the decision support tool is composed of two main modules; data import and data save. Those modules are design 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 sauces in JSON, XML and XLSX formats and respective over the network representations of such structures, like REST, ODATA and WSDL http end points. The output of this module is JSON, which can be invoke as an input for the data saved module. The data save module is designed to consume predefined modeled JSON input in order to represent and build graph based data structures used by the process service match making based on the user specified requirements. This module is able to build up or enrich the data set based on the data specification.

This chapter discusses the use of a decision support system to simplify the choice of services that match functional and non-functional requirements. This DSS uniquely uses risk management techniques to compliment 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 multi-factor optimised expert systems. Cloud services evolving into a wider architectural movement that includes containers and microservices. Cloud services used in a multi-cloud environment linked with microservices and container API are leading to a multi-service 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 is increasingly demanding service description, discovery and matchmaking capabilities that can benefit from decision support of the type described in this chapter. 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 standardisation initiatives and organisations such as the Cloud Security Alliance and Cloud Industry Forum.