Nghiên cứu mô hình chợ ứng dụng đa đám mây TT TIENG ANH

MINISTRY OF EDUCATION AND TRAINING HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY HUYNH HOANG LONG RESEARCHING MULTI-CLOUD MARKETPLACE MODEL Major: Information Systems Code: 9480104 THE SUMMARY OF INFORMATION SYSTEM DISSERTATION Hanoi - 2022 The doctoral dissertation was completed at: Hanoi University of Science and Technology Supervisors: Ph.D NGUYEN HUU DUC Assoc.Prof LE TRONG VINH Reviewer 1: Reviewer 2: Reviewer 3: The Dissertation was approved by Ph.D Thesis Evaluation Board at Hanoi University of Technology …… … , day … month … year ……… The Dissertation is available at: Ta Quang Buu Library-Hanoi University of Science and Technology National Library of Vietnam LIST OF PUBLICATIONS Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, and DucHung Le, “Towards the cloud marketplace for Multi-cloud infrastructures”, In Proceedings of the 18th Vietnam National Conference: Selected issues of information technology and communication, pp 100-105, Ho Chi Minh, November 2015 (In Vietnamese) Hoang-Long Huynh, Van-Dang Tran, Huu-Duc Nguyen, Zhenjiang Hu, Trong-Vinh Le, Quyet-Thang Huynh, “Autoupdating Portable Application Model of Multi-cloud Marketplace through Bidirectional Transformations System”, In Proceedings of the International Conference on Intelligent Software Methodologies, Tools, and Techniques (SOMET 2019), pp 11-24, Malaysia, September 2019 Doi:10.3233/FAIA190035 (SCOPUS Indexed) Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, “Matchmaking for Multi-cloud Marketplace Application”, Journal of Research and Development on Information and Communication Technology, Ministry of Information and Communications, Vietnam, Vol 2019(1), pp 31-42, September 2019 ISSN18593534 DOI:10.32913/MIC-ICT-RESEARCH.V2019.N1.854 Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, ThiNhan Vu, Quyet-Thang Huynh, “An approach for auto-repairing cloud application on Multi-cloud Marketplace”, In Proceedings of the 22th Vietnam National Conference: Selected issues of information technology and communication, pp 17-22, Thai Binh, June 2019 Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, QuyetThang Huynh, “CAM-D: A description method for Multi-cloud Marketplace Application”, Journal of Research and Development on Information and Communication Technology, Ministry of Information and Communications, Vietnam, Vol 2020(2), pp 5161, December 2020 ISSN 1859-3534 DOI:10.32913/MIC-ICTRESEARCH.V2020.V2.943 Chapter 1: Introduction 1.1 Context In general, most SaaS are closely tied to the technical infrastructure of their owners This leads to the problem of tying consumers and application developers into the separate infrastructures of cloud ecosystems This is the cause of vendor lock-in problem in cloud computing, which is characterized by expensive and time-consuming migration of application and data to alternative providers Cloud vendors lock customers in several ways: (i) by designing a system incompatible with software developed by other vendors; (ii) by using proprietary standards or private architectures that lack interoperability with other applications; (iii) by licensing the software under exclusive conditions Thus, vendor lock-in deters organizations adopting cloud technology In our view, it is possible to evolve cloud marketplace model and multi-cloud application model to reduce vendor lock-in if efficiently leveraging the outstanding advantages of the multi-cloud environment 1.2 Thesis research issues Most cloud providers have been building proprietary SaaS platforms where their applications are hosted in a SaaS business model and establishing a series of restrictions for their cloud platforms Hence, these proprietary platforms prevent that applications offered by different SaaS application vendors cannot easily host on the platforms offered by others and the cloud software is developed with their tools will be coupled to the libraries and services provided by each cloud provider This open up the well-known issue: vendor lockin As a result, cloud developers are often locked into specific technological ecosystems The main goal of our studies is to develop a new multi-cloud marketplace model which has a special mechanism to reduce vendor lock-in and a component-based cloud application model by which a cloud application is made up from independent components and spread across various clouds To achieve this goal, we must overcome several issues as follows: Multi-cloud marketplace model, Multi-cloud application model, Matchmaking method of multi-cloud marketplace application, Multi-cloud application portability, Method for auto-repairing multi-cloud application, Service Level Agreement, Cloud application scalability, Security, etc 1.3 Thesis contributions Our main contributions are are described as follows: Proposing O-Marketplace Model, a new multi-cloud marketplace model Presenting Composable Application Model, a new cloud application model for multi-cloud marketplace Beside key models mentioned above, some issues have to be solved to prove the practicality of O-Marketplace Model and Composable Application Model as follows: • Matchmaking method, presenting an advantageous method for matching cloud software components to a cloud platform group in the context of O-Marketplace • Multi-cloud application portability, presenting an approach for multi-cloud application portability and building up a Bidirectional Transformations System to auto-update cloud application modeled by CAM • Multi-cloud application auto-repairing, introducing an approach for auto-repairing cloud application in the context of O-Marketplace Chapter introduces related technologies and related works The cores of thesis are Chapter 3,4 Chapter is Conclusion Chapter O-Marketplace 3.1 Introduction Almost cloud providers currently have their own marketplace such as Amazon,IBM,Google,etc., whereby cloud services are only allowed to operate on their own infrastructures The single-vendor dependence has been binding both consumers and developers to the technology ecosystems of particular cloud providers This is the cause of vendor lock-in In another aspect, Multi-cloud environments use a mix of cloud offerings, sharingthe workloads between them with cloud application could be spread across differentservice providers The multi-cloud approach is very effective for reducing the vendor lock-in To leverage the advantages of multi-cloud environment for reducing vendor lockin and creating a free environment for cloud developers, we propose a new cloud marketplace model, called O-Marketplace It is an independent entity from cloud providers and operated by a third party O-Marketplace is not only as a brokerage center, but also integrates individually developed cloud software components on different cloud platforms to create a complete cloud software So this function facilitates consumers to use multi-cloud applications 3.2 O-Marketplace Model 3.2.1 The proposed cloud service delivery method for multi-cloud marketplace To overcome these restrictions from existing methods of cloud service delivery of cloud marketplace and to leverage the advantages of multi-cloud environment, we propose the method of cloud service delivery for multi-cloud marketplace The main differences of proposed method are as follows: • • • • Cloud service information is transparent (Features, Price, QoS, ) Creating a competitive environment that promote cloud providers have to develop their services to serve the cloud software independently developed by developers Reducing vendor lock-in and increasing value-added consumers and developers Providing multi-cloud application and supporting consumers to deploy and manage the multi-cloud application 3.2.2 Overall structure of O-Marketplace Relying on the proposed cloud service delivery method for multicloud marketplace We build up O-Marketplace Model, which is a multi-cloud marketplace model O-Marketplace provides to customers a catalogue of cloud software and cloud resource services bundles with detailed information about functions, prices, etc of cloud services provided by cloud providers and cloud software vendors/developers Especially, the novelty of O-Marketplace is to provide cloud application that can be distributed across various clouds Therefore, with just one application, customers can consume various cloud services provided by different providers Moreover, OMarketplace lead to create an open market that facilitate developers and cloud providers to sell their products flexibly This is extremely significant for developers who not own cloud infrastructure To express this idea, we sketch O-Marketplace model which has five main building block depicted in Figure 3.6 as follows: (i) Graphical User Interface is a portal that facilitate for consumers to approach cloud application It is a catalogue of cloud services, cloud software and cloud software components provided by the third parties such as cloud application vendors, developers, and cloud providers (ii) O-Marketplace Repository contains cloud software (artifacts, software component specifications, software composition specifications) and cloud platform services (IaaS specifications and PaaS specifications) (iii) O-Marketplace Electronic Commerce Platform has the main functions inherited from the electronic marketplace model (iv) O-Marketplace Runtime Platform includes some main functionalities such as Description, Deployment, Configuration, Migration, Monitoring Especially, O-Marketplace aims to the significant difference compared to the current cloud marketplace models in particular and other cloud service delivery models in general as follows: • Providing the component-based cloud application Cloud software and cloud resources are provided separately A cloud software is a combination of application components which can be developed independently and consume various underlying cloud platform services • Supporting developers to develop individual cloud software components in depth that can host on various cloud platforms Figure 3.6: O-Marketplace Model This novelty in SaaS provisioning is the basis for direct competition mechanism Especially, the separation allows cloud application avoiding vendor lock-in problem 3.2.3 The operation mechanism of O-Marketplace There are four actors involved in the O-Marketplace model as follows: consumer, cloud provider, cloud software vendor/developer and O-Marketplace Administrator as an intermediary The activities of actors have a close relationship with each other in the transaction process In which, O-Marketplace is a brokerage center, providing the best brokerage method to supply cloud applications to consumers 3.3 The goals of O-Marketplace Model O-Marketplace model aims to distinct outstanding advantages described as follows: • Creating a direct competition, bringing the most benefit and convenient way to customers • Towards a diverse cloud application market where developer is the pilot of cloud application development Cloud software products are independently developed and are no longer tied to cloud service providers • There is no outdated solution because cloud software are always adopted by the developer community • A cloud application is a combination of intensive capabilities from orders So promoting cooperation among parties in cloud application development Consumer could can pick the best services from each provider to build his app • Consumers are completely proactive in the service fees they have to pay To sum up, O-Marketplace is not only a vendor-neutral ecosystem which focus on reducing vendor lock-in, but also is an attractive business ecosystem that support facilities, promote and monetize cloud applications as well as create an active community for cloud consumers, cloud providers and developers Chapter 4: Composable Application Model 4.1 Introduction In our view, cloud application should be designed in a fashion that it consume various types of resource offered by cloud providers We propose Composable Application Model (CAM), a componentbased cloud application model in which the cloud software of multicloud marketplace is composed from software components, each of them can be independently developed by different developers and can reside in different clouds Thus, the development of cloud software could not be bound to any specific cloud provider ecosystem 4.2 General concept of CAM In our approach, we adopt component-based application approach, a cloud software is able to spread on a group of compatible cloud platforms to form a cloud application system without having to reengineer or to re-develop Thus, we divide a cloud application into two separated parts: a cloud software and underlying runtime systems, which are provided by particular cloud providers We name this cloud application model is Composable Application Model (CAM) The proposed model is depicted in Figure 4.1 Figure 4.1: Composable Application Model 4.2.1 Cloud application A cloud application is a runtime service that offers specific business functionalities To customers, this refers to a similar concept to Software as a Service (SaaS) Internally, a cloud application Various cloud providers can develop and provide the same kind of cloud platform service, but with different price, QoS, resource capacity, policies, etc In our research scope, we only consider the technical capabilities of cloud platforms for matching them with the proposed software model 4.3 Simple Definition for Composable Application Model 4.3.1 Matching Definition To depict the relationships of components within a cloud application modeled by CAM, we specify two types of dependencies in the multi-cloud application model: software dependence and platform dependence Software dependence denotes the interconnection between two software components The platform dependence denotes deployment capability of a pair of software components or a pair of a software component and a cloud platform We define two elements to make up a dependence: Requirement and Capability Relying on these elements, matching rules is constructed to denote the dependencies within a cloud application Requirement specification, capability specification, and matching condition is defined as follows: • Requirement specification: requirement for short is denoted the dependency of a component on other another component It poses the necessary conditions for component to perform its functionality and behaviors Requested interfaces and properties of a component are encapsulated in requirement We specify two types of requirement: software requirement and platform requirement Software requirement (sreq) is a constraint on the functionality and behavior of another component Platform requirement (preg) is a constraint on the environment and technology of another component 10 • • Capability specification: capability for short denote the available capacity that can meet the request from outside Its functionality and behavior are performed when it satisfies the condition from another external component Responded interfaces and properties of a component are encapsulated in capability We specify two types of capability: software capability and platform capability Software capability (scap) is a supply of the functionality and behaviors of a component Platform capability (pcap) is a supply of the environment and technology of a component Matching condition: we define a dependence between two components is valid if requirement of a component match with capability of the other 4.3.2 Abstract model of Composable Application Model We develop an abstract model of CAM in which we ignore the implementation details of the components but focus on the relationship among components inside a software composition and the relationship between a component and its underlying platforms 4.3.2.1 Multi-component cloud software model In CAM, we define the abstract model of cloud software as a nested structure where each component may be a composition of other components Some of them may again be compositions of other smaller components This approach helps us increasing the degree of reusability since the implementation of a complex component may be reused in other compositions This also motivates the cloud software marketplace where developers can develop and sell their small components instead of complete software solutions We classify component in the model into the following three types: (i) Simple Component; (ii) Stack; (iii) and Composition Figure 4.3 shows the overall structure of CAM and the relationship among these three types of the components 11 Figure 4.3: The formal definition of multi-component cloud software 4.3.2.2 Base Component As shown in Figure 4.4, three types of software components are modeled as subtypes of the Base Component This formalism allows us to treat components of different types uniformly as specializations of the Base Component Each component has its own properties We use the dot-notation to refer to a property of a component For example, X.y is the property y of the component X Since we focus on the relationship among components inside a composition and the relationship between a component and its underlying platforms, the properties of a component should explicitly describe its requirements and capabilities More specifically, as shown in Figure 4.4, a component should have at least the following properties: (1) description of software services provided by the component (software capabilities - scaps), (2) the establishment of runtime environment providing to upper components in a stack manner (platform capabilities - pcaps), (3) descriptions of extra software services required for running the component properly (software requirements - sreqs), (4) and the necessary requirements for underlying platforms to host the component (platform requirements - preqs) The specifications of components, i.e the description of component’s properties, are used for verifying the correctness of software composition and for checking the compatibilities between a component and its underlying platforms These specifications are written by developers, and they are not necessary to collate the actual implementation of the components 12 Instead, developers can select the requirements and capabilities of a component from a predefined set of terms Figure 4.4: Base Component Note that a component may be hosted on multiple cloud platforms from different cloud providers, the platform requirements should be specified for each platform We call degree of a component to be the total number of underlying platforms for hosting the component Thus, the platform requirements for the platform i is defined as pregs[i] 4.3.2.3 Simple Component Simple component is an atomic type of components in CAM In a full definition, a simple component should specify its code and data as well as the necessary specification of requirements and capabilities A simple component is hosted on a single platform (degree = 1) If the set of requirements of a simple component is empty (regs = ), the component can represent a complete cloud software In general cases, a simple component can combine with other components to form a more complex component (Stack or Composition) 4.3.2.4 Cloud software stack A cloud software stack, or stack for short, denotes a sequence of simple components deployed on top of each other vertically For simplicity, we define a Stack in nested manner Each stack has two elements: (1) top element is a simple component lay on top of the stack, (2) and base which is either a simple component or another stack representing the remain components in the sequence 13 Similar simple component, a software stack can only be deployed on a single platform (degree = 1) Beside the advantage of reusability, the combination of multiple components into a single form of stack would help us reducing the cost of deployment and management by combining corresponding operations from the stack’s elements We will discuss this interesting problem in another study from our on-going research Figure 4.5: Cloud software stack When creating a stack, a developer must specify the top element and the base element The developer must also specify the stack requirements and capabilities (i.e sreqs, preqs, scaps, and pcaps), like those mentioned in the Base Component A correct combination of a stack S should satisfy the following validation rules: 4.3.2.5 Cloud software composition Cloud software composition, or composition for short, denotes a set of software components combined in a single form of component to hide the complexity of its own inter-dependency A software composition is considered as a directed graph whose vertex are either a simple component or a stack An edge from a component A to a component B in a composition specifies that the component A consumes services provided by the component B at runtime Similar with stack, we apply the nested structure for defining compositions Each composition consists of a set of components and 14 some of them may be other compositions For simplicity, we define a composition with two elements (Figure 6): the first, and the second The inter-dependence of a composition is restricted to the software dependence of the first to the second Degree of the composition is calculated by the sum of degrees of the first and the second Figure 4.6: Cloud software composition When creating a composition, developers need to specify its external requirements and capabilities At the moment, we not allow extra components to lay on top of a composition So, the property pcaps should be empty The following validation rules should be applied for verifying the correctness of a composition C: 4.3.2.6 Cloud platform Cloud platform, or platform for short, is used for modeling the cloud platform profile in a cloud marketplace A specification of a single platform P should describe its capabilities (pcaps) in order to match with the platform requirements (preqs) of cloud software components which are aimed to deploy on it Practically, the specification of a platform is provided by the cloud provider or a service broker such as cloud marketplace In this case, developers and cloud providers should agree on the same set of predefined terms of the platform requirements and capabilities Figure 4.7: Cloud platform 15 A cloud software composition may require more than one platform We define platform group as an order set of cloud platforms, and compatible platform group as a platform group that satisfies the platform requirements of a composition The following predicates are used for checking this property At the time of software deployment, platform compatibility should be checked to ensure that the software component will work fine on the underlying platform 4.4 Description Templates of CAM (CAM-D) With the motivation to standardize the multi-cloud application description in a uniform, we define a description method that is not only capable of expressing its behaviours and properties in standardized description patterns, but also meet the multicloud characteristics in general and O-Marketplace in particular To achieve this goal, our work focuses on developing description templates for entire CAM and its components The description of CAM application is built from individual descriptions based on the matching rules Because CAM is defined as a nested structure, so the description method has to express this special feature The description templates is available at: https://github.com/longlovehl/CAM-D/ 4.5 Experimentation of Composable Application Model To transform a CAM-D application script to TOSCA topology template, we apply a two-step process: Flattening the given CAM-D application script into a flattening composition; Transforming the flattening composition to TOSCA topology template 16 4.6 Applications of Composable application model in the context of O-Marketplace 4.6.1 CAM-based matchmaking method for OMarketplace 4.6.1.1 The proposed approach for matchmaking method Related matching solutions have limitations as follows: (i) the compatibility and the dependencies among components in a multicomponent cloud application is not considered; (ii) these matching solutions have not been fully defined in a specific multicloud application pattern; (iii) There is no paper mentioned about matchmaking a component-based cloud software and its runtime systems delivered by different cloud providers To tackle this issues, the proposed approach to explicitly specify the technological constraints among software components and between a component and its expected underlying runtime platforms by matching rules to verify the correctness of software composition and deployment Beside, we develop a matchmaking algorithm to retrieve a group of compatible cloud platforms for a component-based cloud software that suits with a criteria set ordered by cloud consumer On this basis, a CAM-based multi-cloud application is made up 4.6.1.2 Matchmaking Context To facilitate the suggestion feature of the multi-cloud marketplace, relying on CAM concept, we develop a matchmaking method of which algorithm would help consumers to find suitable platforms to host a specific cloud software by matching the platform requirements of the cloud software to the capabilites of the cloud platform service 4.6.1.3 Matchmaking algorithm We assume that a platform solution for hosting a cloud software component C is a compatible platform group PG to the component C 17 There may be more than one solution existed since several cloud providers may offer a same kind of platform (with different price and quality of service) Choosing an optimal solution means that we need to make a comparison among the solutions based on a designated cost function We call Cost(PG) for the cost function of a platform solution, i.e the platform group PG Some reasonable examples for the cost function would be: 𝑑−1 𝐶𝑜𝑠𝑡([𝑃0 , … , 𝑃𝑑−1 ]) = ∑ 𝑃𝑟𝑖𝑐𝑒(𝑃𝑖 ) 𝑖=0 This cost function would help customers to select a platform solution with optimal price 𝐶𝑜𝑠𝑡([𝑃0 , … , 𝑃𝑑−1 ]) = |{𝑃0 , … , 𝑃𝑑−1 }| This cost function would help customers to select a platform solution with a smallest number of platforms will be used Using such a cost function, we develop a matchmaking algorithm for suggesting compatible platform solution as shown in the following pseudo code 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 Algorithm Matchmaking(C, PS); Input: - A cloud software component C - A set of cloud platforms PS Output: - A compatible platform group PG to the component C whose members are selected from PS Begin d := C.degree; For i := to d – Begin CPL[i] := ; For each P  PS If compatibleWithReqs(P, C.preqs[i]) Then CPL[i] := CPL[i]  {P}; End min_cost := INFINITY; best_solution := NULL; For each PG in (CPL[0] x CPL[1] x … x CPL[d - 1]) If Cost(PG) < min_cost Then Begin 18 23 min_cost := Cost(PG); 24 best_solution := PG; 25 End; 26 Return PG; 27 End; 4.6.2 CAM-Based Portability Multi-cloud Application 4.6.2.1 The proposed approach for enhancing multicloud application portability In our approach, the Blueprint is cloud application orchestration plans; it is the basis for deploying and configuring a multi-cloud application If there is a change in the cloud platform service, the Blueprint will also be modified by attributes of a new cloud platform specification The updated Blueprint is used for re-deploying one or several software components and re-establishing relevant inter-connections To ensure that the Blueprint is updated correctly by construction, bidirectional transformations (BX) is an effective approach for accurate synchronization, automatically derived from bidirectional program In this way, the portability of cloud software is enhanced by creating pressure on cloud providers to increase the compatibility of underlying runtime systems with independently developed cloud software in the upper layer The proposed approach is an efficient way for managing the cloud application because all properties of components within a cloud application and the dependencies between them are organized in the Blueprint Software components of a multi-cloud application can be explicitly re-deployed on new cloud platform services (other clouds) and re-established relevant inter-connections based on orchestration plan totally de-rived from such Blueprint Finally, the operation of cloud application is as an initialstate 4.6.2.2 Method for Auto-updating Cloud Application Blueprint Our ideal is to provide assistance and tooling to update a cloud software model This framework aims to enable to update the application model with new properties from specifications of new compatible cloud 19 environments This approach has the ability for adapting the most extensive amount of technologies and the major shift in technology trends Other approaches cannot offer support for much-targeted technology Our approach has the ability for adapting the most extensive amount of technologies and the major shift in technology trends Cloud software components could be portable on top of various cloud PaaS or IaaS Porting process is based on the Blueprint of cloud application which is modeled by Composable Application Model The overview of our method is depicted in Figure 4.24 When any software component is selected to move to other platform component which is compatible with such software component after verifying the conformity, the Blueprint is immediately auto-updated with new attributes which are derived from target platform component specification Figure 4.24: Auto-updating cloud application’s Blueprint process 4.6.3 CAM-Based method for auto-repairing multicloud application 4.6.3.1 The proposed approach for auto-repairing multicloud application We propose a promising approach for auto-repairing these faulty service components by using Blueprint for representing a multi-cloud application, which is modeled by CAM Blueprint provides a comprehensive overview of the structure of cloud applications are active 20 It is very useful mechanism for finding error of service components within the application by monitoring based on the cloud application structure In this approach, CAM is the Blueprint which is cloud application orches-tration plan and is the basis for deploying and configuring a multi-cloud application Hence, cloud application is autorepaired by re-deploying the failed component(s) and re-established application interconnection(s) so that the operation of the cloud application is as an initial state 4.6.3.2 Procedure of multi-cloud application autorepairing Auto-repairing procedure operates on the supplied Blueprint which depict all relations of its component There are three steps as follows: Step 1: multi-cloud failure detection monitors the operations of cloud application service components and detect failures based on the status of each component based on the connection statuses according to the relationship depicted in the blueprint This work need to determine clearly the type of failure Step 2: if a failure is detected, send request to multi-cloud runtime engine Step 3: analyzing the request to determine the type of failure, then re-deploying software component on existing cloud platform or new cloud platform and re-establishing relevant interconnections 4.7 Discussions of Composable Application Model Composable Application Model is not only the core of solutions related to the evolution of O-Marketplace, but also plays a key role in cloud application development 21 4.7.1 The role of CAM in O-Marketplace model Composable Application Model alters the role of suppliers to add values to both developers and consumers because its structure assists in reducing vendor lock-in and benefit consumers On the developer side, CAM plays an important role in creating the ideal environment for multi-cloud software development Instead of being dependent on service providers as before, developers become pilots for the cloud market development as well as promoting cloud providers to improve their cloud technology to adapt cloud software technical requirements Developers could be free to develop and sell their cloud software components which are developed separately of any cloud provider ecosystem Moreover, a cloud application is able to develop by more than one developer On the supplier side, CAM-based application development are not bound to the narrow scope of each cloud provider This brings the great change in the role of the cloud service providers, from being in dominance in the cloud market to become partners with third parties/developers in providing cloud runtime systems Beside, the diversity of technological environment of the cloud software layer is the heavy pressure for cloud providers in the development and improvement of runtime systems to meet the technology requirements of cloud software in the upper layer On the consumer side, CAM facilitates consumers to exploit the most advanced features from cloud providers by only choosing best platform services for their needs to host appropriate components instead of a full SaaS solution On the multi-cloud marketplace side, CAM is the key foundation for the multi-cloud service delivery method and operation mechanism of O-Marketplace Cloud software or components are released on the multi-cloud marketplace without having to care about the application execution environment, this is the driving force of direct competition 22 So, the quality and features of cloud products are constantly improving, cloud services are increasingly diverse 4.7.2 The role of CAM in cloud application development CAM-based cloud application may be constructed as a distributed system of which components are compute servers running specific software components and located at specific cloud providers Software components can be intuitively and flexibly integrated to represent specific behavior because component-based cloud software is organized as nested structure The underlying platforms can be simply identified because cloud infrastructures and cloud platform service profiles are covered in a uniform and abstracted as components within a component-based cloud application Cloud software development is liberated from the constraints of technology from any cloud provider Developers could develop small pieces instead of complete software solutions Software components within a cloud application can be separately developed on various cloud technology platforms which differ in functionality and deployment capability Enhancing the ability to reuse cloud software components, developers can build up a multi-component cloud software by just incorporating existing cloud software components of others into their cloud software solution This save cost and time in cloud application development 23 Chapter 5: Conclusion and Perspectives 5.1 Conclusion Our studies expressed in this thesis was carried out in the emerging context of multi-cloud environment with issues linked to the multicloud marketplace model, the independent cloud application development and distributed deployment of cloud application on multi-cloud Focusing on these challenges, our works achieved results: • Creating a direct competition environment for cloud services; • Defining multi-cloud application model; • Reusing cloud software components; • Presenting a matchmaking for multi-cloud marketplace; • Value-added cloud developers; • Value-added cloud consumers 5.2 Future works The contributions presented in this thesis open multiple research routes for the future works, including both short term and long term perspectives The routes for short term perspectives: • Improvement of O-Marketplace, • Improvement of CAM, • Extension of CAM evaluation, • Developing CAM-runtime The research routes for long term perspectives: • Mechanism for managing SaaS on multi-cloud, • QoS/SLA, • Security, • Migration 24 ... https://github.com/longlovehl/CAM-D/ 4.5 Experimentation of Composable Application Model To transform a CAM-D application script to TOSCA topology template, we apply a two-step process: Flattening... a two-step process: Flattening the given CAM-D application script into a flattening composition; Transforming the flattening composition to TOSCA topology template 16 4.6 Applications of Composable... the compatibilities between a component and its underlying platforms These specifications are written by developers, and they are not necessary to collate the actual implementation of the components