A Marketplace Broker for Platform-as-a-Service Portability

A Marketplace Broker for Platform-as-a-Service Portability Bholanathsingh Surajbali1 , Adri´an Juan-Verdejo1,2 1 Smart

Research Development Centre, CAS Software AG, Karlsruhe, Germany 2 Information Systems Chair, Stuttgart University, Germany {b.surajbali, adrian.juan}@cas.de

Abstract. Platform as a Service (PaaS) has become a strong technological solution in particular for small medium enterprises (SMEs) to achieve cost savings and rapid time to market of their software solutions. However, for SMEs how to choose the PaaS provider becomes a bottleneck due to the number of offerings each PaaS vendor offers. Another challenge often faced by enterprises is how to match their software system requirements to PaaS offerings. Furthermore, searching for the best PaaS offering is even more difficult when enterprises need to migrate their existing software solutions from one PaaS vendor to another. In such cases, the portability of the enterprises data and application components becomes cumbersome. If their software solutions are bound to a specific PaaS provider, enterprises suffer from vendor lock-in. This paper addresses these portability challenges by proposing a high-level architecture to ease the portability of software solutions over PaaS vendors taking into consideration the various life-cycle stages, such as identifying and analysing Paas offerings in the market; selecting the best PaaS offering according to organisation’s requirements; and the deployment, management, and monitoring of the software solutions.

1

Introduction

Platform as Service (PaaS) has established itself as the lynchpin for organisations to take advantage of the decreased information technology (IT) costs and increasing application development performance. PaaS offerings offer a higher-level development platform which hides low-level details from the developer, such as the operating system, the load balancing, and the data storage and access. This developing platform enables programmers to write code and create applications without worrying about software versioning or limited infrastructure resources. A PaaS vendor provides a runtime framework which enables developers to program the application’s code and execute it. For example, libraries and application programming interfaces (APIs) which give access to the computational and storage resources. In particular, organisations can take advantage of productivity gains which allow them to develop and deploy their applications. By leveraging PaaS faster application testing and deployment, development teams can easily try different configuration, assess application’s performance, and identify compatibility issues. From a business perspective, PaaS allows enterprises to focus on their core business interests. However, PaaS are becoming increasingly complex due to offerings heterogeneity, such as the number of runtime or services supported making it harder for enterprises to choose among PaaS vendors. These include, but are not limited to efficient deployment,

security of PaaS provider—e.g. secure protocols, QoS guarantees, trust issues, and cost sharing models. In addition, enterprises may face the vendor lock-in problem when they want to migrate their system from one PaaS provider to another one. These are due to lack of PaaS vendors compliance to standards which makes the portability of data, application, and infrastructure difficult. But even if portability is supported in theory, the high complexity and the switching costs still discourage organisations from porting their applications [1]. Furthermore, new PaaS vendors face tough competition to make their offerings available to enterprises with giant vendors having suitable marketing and financial backing to publicise their offerings and cope with losses. Enterprises developing applications should be able to choose between different Cloud PaaS offerings by selecting the most reliable, well-reputed, or cost-efficient offering; or simply the one that meets their technical requirements. Organisations should also be able to switch easily and transparently between PaaS providers whenever needed— for example, when a Service-Level Agreement (SLA) is breached or when the cost is too high—without setting data and applications at risk—for example, loss of data or inability to run the application on a different platform. Moreover, they should be able to compare PaaS offerings with different characteristics—such as resource, pricing or Quality of Service (QoS) model—and to choose the one that best matches the computing needs of their services and applications [2]. In this paper, we propose a PaaS Marketplace to allow PaaS provider selection according to the organisation’s offerings, and to assess the application’s portability to increase the level of service and minimise the potential occurrence of any vendor lockin problem. The rest of the paper is structured as follows. In section 2, we describe the main motivation to build the broker marketplace using a use-case scenario. Next, in Section 3, we describe the PaaS offerings taxonomy. Next, in Section 4, we provide a discussion on the related work. Finally, in Section 5, we provide the conclusion and future work.

2

Marketplace Use Cases

A myriad of PaaS service offerings exist today and it is difficult for organisations to select the most adequate PaaS environment for them. Organisations choose depending on the PaaS environment capabilities and requirements. At the same time, they consider potential compatibility issues with their software components, the services offered by the PaaS environment, and potential interoperability and portability issues. To illustrate the complexity around PaaS selection and application adaptation we use the Business Intelligence (BI) portability scenario [3] as an explanatory example. 1. Portability of a BI application from a legacy information system to a PaaS offering. Organisations have different interdependent constraints to port their BI applications from one PaaS environment to another one; and want to achieve specific objectives in different dimensions. Nevertheless, when they improve the system in a dimension, as increased data storage, they could damage the system in another one, for example cost reduction. These dimensions are not always equally important to all organisations and they can trade one for another one. An organisation

cannot overcome some of the constraints. As an example, one organisation might not be allowed to move its BI data to a public PaaS environment. The nature of the application components to be ported, the application’s users, and the offering gained by porting the BI application to PaaS environments and how to choose the best offerings are crucial decisions for organisations. 2. Partial portability of BI business logic or data layers. An organisation can choose to move only part of the BI layers to the PaaS offering. For instance, for security reasons, an organisation may choose to keep the data layer on its premises while using BI tools in cloud environments to extract information from those data. At the same time, the organisation needs to make sure the system’s performance is not affected by such a portability. 3. Portability of a PaaS BI application from one PaaS platform to another. The BI software engineer must evaluate each PaaS offering to reduce the effort to adapt its BI application to the new PaaS environment. The selection of the PaaS offering which requires less adaptation of the ported application reduces costs. The adaptation effort depends on the levels of portability transparently. That is, the portability achieved without using any additional software, changing the application settings, or putting the application and data at risk. 4. Portability of a BI application to a PaaS offering provided by a new cloud provider within the marketplace. This scenario is related to how a new PaaS provider joins the marketplace—Manage User Profile use case. The marketplace offers a graphical user interface with credential access to let PaaS providers seamlessly join the marketplace and transparently exchange data and applications with other PaaS providers—Manage Semantic Profile of Application use case. From a business perspective, PaaS providers access a large pool of potential customers to form alliances or build their competitive advantage.

3

PaaS Offerings Taxonomy

Based on the use cases presented and the BI example, we show in Fig. 1 the six PaaS offerings dimensions in which PaaS offerings differentiate from one another: Application Dimension. It is an essential dimension related to the application under migration and consists of four sub-dimensions i) Application Framework; ii) Extensibility; iii) Services; and iv) Status. The framework represents the underlying framework used to build the application, which can be for instance the language framework such as Java, .Net Framework, Spring; or computing framework such that Java EE, JBoss. The Extensibility sub-dimension represents application extensibility capability once it has been deployed and these can be in terms of built-in application monitoring, logging, and message queuing technologies. The services sub-dimension describe the application services by which can be native or add-on services. A native service is typically part of the PaaS application—such as the data storage service; while an add-on service is a third-party service integrated with the application—for example a search engine. The status of the application describe the deployed application in terms of beta or final release version. SLA Dimension. The SLA specifies the PaaS offering service contract in terms of the quality of service (QoS), pricing model, geographical coverage, maintenance, and

Fig. 1. PaaS Offerings Dimensions

energy consumption of the applications/data. The QoS describes the response and resolution times the application service requests, providing the minimal, acceptable and maximal level of QoS supplied by the PaaS provider. Next, the pricing model, describe what PaaS providers usually charge according to resources usage. For instance, billing can be fixed, metered, or hybrid [4]. the geographical coverage, describes the multigeographical deployments offerings of the PaaS provider. For an organisation subscribing to a PaaS vendor, the geographical location presents legal concerns. For instance, EU-based companies are not allowed to transfer any of their customer-related data outside of the European Union [5]. The availability sub-dimension, describes the PaaS providers commitment to provide a certain level of availability for their PaaS offering. Finally, the energy-consumption sub-dimension describes, the application and data energy consumption through the PaaS provider. Deployment Dimension. PaaS vendors provide tools to validate and test the deployment of application and data components. These tools vary from model-driven approaches [6] to organisations requirements validation tools [7], and software development life-cycle tooling facilities. Additionally, once deployed PaaS providers offer a number of tools can monitor application and data components performance based on usage and report back to organisations to ensure proper QoS.

Security Dimension. The security dimension of a PaaS offering is crucial for organisations PaaS selection and to let them assess the overall application security levels achieved. As from our use case scenario about BI applications, the data layer represents the asset of the BI user organisation interested on porting the BI system to PaaS environments. The portability of this layer to PaaS environments poses important security concerns for the organisation related to the trustworthiness of the PaaS provider in charge of storing the data layer. The portability process itself has to keep data integrity and let users access them effectively. For example some users work with the data from different geographical locations. We consider three BI portability models: i) private PaaS model whereby the organisation wants to ensure total data ownership through self data security enforcement; ii) public PaaS model whereby the organisation trust cloud provider offerings; and iii) a hybrid PaaS model whereby the system can use more computational resources on demand while keeping sensitive data in the organisation premises. Portability Dimension. PaaS offerings provide information on the different standards they comply to in order to ensure application and data portability or recommend portability methodologies. Standards range from cloud standards such as Open Cloud Computing Interface (OCCI) [8], The Topology and Orchestration Specification for Cloud Applications (TOSCA) [9], or Cloud Infrastructure Management Interface (CIMI) [10]; to PaaS standards such as OASIS Cloud Application Management for Platforms (CAMP) which help avoiding vendor lock-in. Usability Offering. PaaS providers support application development with a set of rapid PaaS application development tools. PaaS vendors offer offerings with different levels of support. Furthermore, PaaS offerings application and database usability varies as well as the training and documentation they offer. The usability dimension determines the application and database knowledge needed to maintain and extend an application deployed to a PaaS offering.

4

PaaS MarketPlace Broker Architecture

The PaaS marketplace broker architecture in Fig. 2 consists of three tiers: i) the PaaS Front-End Tier; ii) the PaaS Selection and Assessment Tier; and iii) the PaaS Portability Tier. PaaS Front-End Tier. The PaaS front-end tier comprises the Paas Marketplace Broker allowing end users to track PaaS offerings, services, interdependencies, and offers. The main goal of the marketplace broker is to make it easier, safer, and more productive for PaaS adopters to navigate, integrate, consume, extend, and maintain cloud services. In this respect, the broker offers a range of added-value services to both PaaS vendors and consumers. It supports seamless interaction between the PaaS consumer and the PaaS offering. Paas consumers interact with the PaaS marketplace broker to find available PaaS offerings which comply to their application’s requirements and their criteria for porting their application. Additionally, the broker supports the actual application porting to PaaS environments. PaaS Selection and Assessment Tier. The PaaS Selection and Assessment tier selects and assesses the existing PaaS offerings and contains three modules: The In-

Fig. 2. PaaS Marketplace Architecture

CLOUDer Decision Framework [7] supports the PaaS offering selection and application porting. InCLOUDer discards PaaS offerings which cannot support the application to be ported. Further, InCLOUDer follows the Analytical Hierarchy Process [11] to recommend strategies to port an application to a different PaaS offering and rank all these porting alternatives. This module implements core functionalities such as PaaS offering discovery, PaaS Offering Analysis, and PaaS recommendation. InCLOUDers reasons according to the application’s architecture, requirements, and constraints. It finds suitable PaaS offerings to port the application and maximises the criteria a particular organisation wants to achieve by porting that application to candidate PaaS offerings. InCLOUDer calculates the local rankings for every alternative based on the portability criteria. These criteria depend on the PaaS offerings dimensions described in Section 3. Finally, InCLOUDer produces a final rating incorporating the knowledge about the application, the portability criteria, and the PaaS offerings information. The Paas Offering Rating Module lets a Software SMEs Engineer rate a particular PaaS offering. Each engineer can leave a comment and rate a particular PaaS offering, thus expressing their satisfaction or dissatisfaction with regards to quality, usability, reliability, and user-friendliness of the offering. This knowledge gathered is fed back to InCLOUDer to enhance the PaaS offering description and selection. The PaaS Offering Repository, on top of which we build the marketplace to interact with heterogeneous PaaS offerings. PaaS Portability Tier Once the PaaS selection and assessment tier recommends a PaaS offering, the PaaS portability tier helps with the actual application deployment and portability from one PaaS vendor to another one. Our Portability Framework handles the application dependencies in the deployment, undeployment, start, stop, and portability of an application to the target PaaS provider. The dependencies range from operating system to executable formats, including compilers and libraries.

5

Discussion and Related Work

Selecting the PaaS offerings which best matches organisations’ criteria to move applications to PaaS offerings is a current and interesting research topic [12]. In this

respect, organisations interested in moving their applications to a PaaS environment need to identify PaaS vendors offerings and access a classification of them. Several research works address the multi-criteria cloud selection. In [13], [4], the authors discuss a methodology for multi-criteria cloud selection as Maiya [14] proposes the use of cloud ontologies to be able to do so. Cloud4SOA [15] proposes the use of semantics to identify the best PaaS offerings and similar to our approach Cloud4SOA proposes a PaaS API for portability from one PaaS provider to another. However, Cloud4SOA differs from our approach in that it requires the annotation of each PaaS Provider offerings, and the annotation process of each offering is only feasible if there are established benchmark of PaaS offerings so that all PaaS vendors offerings can be taken into consideration. The mOSAIC project [16] focuses on application portability at both IaaS and PaaS using a Cloud ontology to analyse the offerings of the cloud and using similar to our approach uses a brokering mechanism, to search offerings requirements. There are numerous efforts from Cloud API standardisation to unify incompatible APIs from PaaS providers CAMP [17], OCCI [8], CIMI [10]. However, th standard on portability is a concern when applications need to be migrated from one PaaS provider making use of one standard and another PaaS provider using a different standard. Porting from one provider to another one brings in these cases portability and standard lock-in issues. To address standard lock-in we use our middleware layer and port applications by leveraging an approach to allow cross-standard to interoperate with each other [18] .

6

Conclusion and Futurework

In this paper we propose a PaaS Marketplace broker to allow PaaS vendors (in particular SMEs) to roll out PaaS offerings leveraging their competitive advantage and the quality of service delivered to their customers, making their offerings more attractive and improving their outreach to potential customers in the software industry. Our approach will facilitate the identification and deployment of business applications on the best-matching PaaS offerings using our InCLOUDer framework. InCLOUDer uses the hierarchy of PaaS offerings making it easier for organisations to weight different PaaS offerings to one another and ranks the best PaaS offerings in accordance with how determinant it is for the success of the application portability. As future work we plan to address the challenges with respect to standard lock-in and security concerns as discussed in Section 5.

Acknowledgement This work is part of the RELATE project supported by the European Commission under the 7th Framework Programme FP7 with Grant Agreement No. 264840 ITN and the PaasPort European Commision project under the 7th Framework Programme FP7SME-2013-605193.

References 1. Joe, M.: Does platform as a service have interoperability issues (2010) 2. Borenstein, N., Blake, J.: Cloud computing standards: Where’s the beef? Internet Computing, IEEE 15 (2011) 74–78 3. Juan-Verdejo, A., Surajbali, B., Baars, H., Kemper, H.G.: Moving business intelligence to cloud environments. In Proceedings IEEE INFOCOMM, Cross Cloud 2014, Toronto (2014) 4. Kolb, S., Wirtz, G.: Towards application portability in platform as a service. (In: Proceedings of the 8th IEEE International Symposium on Service-Oriented System Engineering (SOSE). IEEE, Oxford, United Kingdom (April 7–10 2014)) 5. Strobl, J., Cave, E., Walley, T.: Data protection legislation: interpretation and barriers to research. BMJ: British Medical Journal 321 (2000) 890 6. Fleurey, F., Steel, J., Baudry, B.: Validation in model-driven engineering: testing model transformations. In: Model, Design and Validation, 2004. Proceedings. 2004 First International Workshop on, IEEE (2004) 29–40 7. Juan-Verdejo, A., Zschaler, S., Surajbali, B., Baars, H., Kemper, H.G.: Inclouder: Effective partial migration of pre-existing applications to the appropriate cloud environment, In Proceedings 40th Euromicro Conf. Software Engineering and Advanced Applications (SEAA 2014) (2014) 8. Edmonds, O.W.A.: Open cloud computing interface-infrastructure. Deliverable GFD 184 (2011) 06 9. Binz, T., Breitenb¨ucher, U., Haupt, F., Kopp, O., Leymann, F., Nowak, A., Wagner, S.: Opentosca–a runtime for tosca-based cloud applications. In: Service-Oriented Computing. Springer (2013) 692–695 10. Initiative, C.M.: Cloud infrastructure management interface (2014) 11. Saaty, T.L., Vargas, L.G.: Models, methods, concepts & applications of the analytic hierarchy process. Volume 1. Springer (2001) 12. Petcu, D.: Portability and interoperability between clouds: challenges and case study. In: Towards a Service-Based Internet. Springer (2011) 62–74 13. Hussain, F.K., Hussain, O.K., et al.: Towards multi-criteria cloud service selection. In: Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2011 Fifth International Conference on, IEEE (2011) 44–48 14. Maiya, M., Dasari, S., Yadav, R., Shivaprasad, S., Milojicic, D.: Quantifying manageability of cloud platforms. In: Cloud Computing (CLOUD), 2012 IEEE 5th International Conference on, IEEE (2012) 993–995 15. D’Andria, F., Bocconi, S., Cruz, J.G., Ahtes, J., Zeginis, D.: Cloud4soa: Multi-cloud application management across paas offerings. In: Proceedings of the 2012 14th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, IEEE Computer Society (2012) 407–414 16. Petcu, D., Di Martino, B., Venticinque, S., Rak, M., M´ahr, T., Lopez, G.E., Brito, F., Cossu, ˇ R., Stopar, M., Sperka, S., et al.: Experiences in building a mosaic of clouds. Journal of Cloud Computing 2 (2013) 1–22 17. OASIS: Cloud application management for platforms version 1.1 draft 03 (2014) 18. Bromberg, Y.D., Grace, P., R´eveill`ere, L.: Starlink: runtime interoperability between heterogeneous middleware protocols. In: Distributed Computing Systems (ICDCS), 2011 31st International Conference on, IEEE (2011) 446–455