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

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

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 Duc-Hung Le, “Towards the cloud marketplace for Multicloud 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 ISSN1859-3534 DOI:10.32913/MIC-ICTRESEARCH.V2019.N1.854 Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, ThiNhan Vu, Quyet-Thang Huynh, “An approach for autorepairing 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, Quyet-Thang 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 51-61, 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 lock-in 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 hapter 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 singlevendor 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 lock-in and creating a free environment for cloud developers, we propose a new cloud marketplace model, called OMarketplace 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 10 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 Instead, developers can select the requirements and capabilities of a component from a predefined set of terms 19 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 20 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 ongoing 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 21 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 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 22 and cloud providers should agree on the same set of predefined terms of the platform requirements and capabilities Figure 4.7: Cloud platform 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/ 23 4.5 Experimentation Application Model of Composable 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 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 24 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 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: This cost function would help customers to select a platform solution with optimal price 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 Algorithm Matchmaking(C, PS); 01 Input: 25 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 - 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 min_cost := Cost(PG); best_solution := PG; End; Return PG; 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 interconnections 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 26 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 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 27 Figure 4.24: Auto-updating cloud application’s Blueprint process 4.6.3 CAM-Based method for auto-repairing multi-cloud application 4.6.3.1 The proposed approach for auto-repairing multi-cloud 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 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 auto-repaired by re-deploying the failed component(s) and reestablished application interconnection(s) so that the operation of the cloud application is as an initial state 28 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 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 29 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 So, the quality and features of cloud products are constantly improving, cloud services are increasingly diverse 30 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 31 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 multi-cloud 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, 32 • QoS/SLA, • Security, • Migration 33