Analysis of the state of the art and defining the scope

Transcription

1 Grant Agreement N FP Title: Authors: Editor: Reviewers: Analysis of the state of the art and defining the scope Danilo Ardagna (POLIMI), Giuliano Casale (IMPERIAL), Ciprian Craciun (IEAT), Michele Ciavotta (POLIMI), Emanuele Della Valle (POLIMI), Elisabetta Di Nitto (POLIMI), Mozhdeh Gholibeigi (POLIMI), Peter Matthews (CA), Marco Miglierina (POLIMI), Juan F. Pérez (IMPERIAL), Cosmin Septimiu Nechifor (SIEMENS), Craig Sheridan (FLEXI), Weikun Wang (IMPERIAL) Victor Muntés (CA) Francesco d Andria (ATOS) and Franck Chauvel (SINTEF) Identifier: Deliverable # D6.1 Nature: Report Version: 1 Date: March 29 th, 2013 Status: Diss. level: Final Public Executive Summary This deliverable presents a state of the art analysis of cloud monitoring techniques, the tools available for managing QoS in the cloud, and the techniques available for automatically deploying applications on the cloud. Furthermore, performance models which can be used to quickly estimate cloud systems runtime performance and resource management techniques for optimizing the use of cloud resources from the software provider perspective. This deliverable also specifies the requirements for the MODAClouds run-time environment developed within WP3 and defines a road-map for the work package. Copyright 2012 by the MODAClouds consortium All rights reserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/ ] under grant agreement n (MODAClouds).

2 Members of the MODAClouds consortium: Politecnico di Milano Stiftelsen Sintef Institute E-Austria Timisoara Imperial College of Science, Technology and Medicine SOFTEAM Siemens Program and System Engineering BOC Information Systems GMBH Flexiant Limited ATOS Spain S.A. CA Technologies Development Spain S.A. Italy Norway Romania United Kingdom France Romania Austria United Kingdom Spain Spain Published MODAClouds documents These documents are all available from the project website located at Public Final version 1.0, March 29 th

3 Contents 1. INTRODUCTION CONTEXT AND OBJECTIVES MODACLOUDS RUN- TIME ENVIRONMENT VISION Goals and Technical Assumptions MAPE- K Loop Conceptual Architecture OVERVIEW STATE- OF- THE- ART: RUN- TIME PLATFORMS PREAMBLE Criteria DEPLOYMENT APPROACHES PaaS solutions Deployment and execution solutions Deployment solutions FP7 projects Infrastructures RESOURCE ALLOCATION, LOAD- BALANCING Load balancing and scheduling algorithms Load balancing in production systems APPLICATION DATA MANAGEMENT AND MIGRATION STATE- OF- THE- ART: CLOUD MONITORING PREAMBLE GENERAL MONITORING APPROACHES The COMponent Performance Assurance Solutions (COMPAS) [Mos02]: TestEJB [Mey04]: Performance Anti- pattern Detection (PAD) [Par08 ]: An elastic Multi- layer monitoring approach [Kon12]: RMCM, A Runtime Model Based Monitoring Approach for Cloud [Sha10]: The Multi- layer Collection and Constraint Language (mlccl) [Bar12] Infrastructure monitoring in current IoT landscape INFRASTRUCTURE- LEVEL MONITORING Guest VM monitoring Host machine monitoring Cloud Infrastructure- level monitoring Cloud- specific monitoring APPLICATION- LEVEL MONITORING A Run- time Correlation Engine (RTCE- based approach) [Hol10] CASViD, an SNMP- based monitoring approach for SLA violation [Eme12]: A multi- layer approach for cloud application monitoring [Gon11] Cloud Application Monitoring: the mosaic Approach [Rak11] M4Cloud, A Generic Application Level Monitoring [Mas11] REMO, a Resource- Aware Application State Monitoring approach [Men08] Cloud4SOA COST MONITORING AND MEASUREMENT INDEXES Unified Service Description Language Service Measurement Index STATE- OF- THE- ART: QOS MANAGEMENT PREAMBLE QOS DATA ANALYSIS AND FORECASTING Public Final Version 1.0, March 29 th

4 Problem Overview of data analysis, forecasting techniques, and queueing models Statistical Inference for QoS model parameterization Workload forecasting methods RUN- TIME QOS MODELS Statistical learning models Control theory models Product- form queueing networks Layered queueing networks Summary SLA MANAGEMENT Problem Solution Discipline State of the art Summary tables Criteria for evaluation MODACLOUDS RUN- TIME PLATFORM OVERVIEW Actors Requirement Sets Requirement Elicitation Methodology EXECUTION REQUIREMENTS Context and System Overview Use case specification for the Run Application use case Use case specification for the Deploy Application use case Use case specification for the Start/Stop Application Sandbox use case MONITORING REQUIREMENTS Context and System Overview Use case specification for the Install Monitoring Rule use case Use Case Specification for the Activate/Deactivate Monitoring Rule use case Use case specification for the Add/Remove Observer use case Use case specification for the Collect Monitoring Data use case Use case specification for the Distribute Data use case ANALYSIS OF REQUIREMENTS Context and System Overview Use case specification for the Correlate Monitoring Data use case Use case specification for the Estimate Measure use case Use case specification for the Forecast Measure use case Use case specification for the Feedback Measure use case SELF- ADAPTIVITY REQUIREMENTS Context and System Overview Use case specification for the Define/Undefine QoS Constraints use case Use case specification for the Start/Stop Feedback of Self- Adaptivity Data use case Use case specification for the Define/Undefine Cost Constraints use case ROADMAP REFERENCES APPENDIX A RUN- TIME PLATFORM EVALUATION CRITERIA Public Final version 1.0, March 29 th

5 Acronyms API ARIMA ARMA AWS CDN CEP CLI CUI DSS ECA EJB FA GAE HTTP IaaS IDE IoT IP JDO JMX JNI JSON JSQ LC LLC LLCR LVS MAPE-K OS OVF PaaS QoS REST RHEL ROI RR Application Programmable Interface Autoregressive Integrated Moving Average Autoregressive Moving Average Amazon Web Service Content Delivery Network Complex Event Processing Command Line Interface Console User Interface Decision Support System Event Condition Action Enterprise Java Beans First Available Google App Engine Hypertext Transfer Protocol Infrastructure as a Service Integrated Development Environment Internet of Things Internet Protocol Java Data Objects Java Management Extensions Java Native Interface JavaScript Object Notation Join-the-shortest-queue Least-Connections scheduling Locality-based Least-Connections scheduling Locality-based Least-Connections scheduling with replications Linux Virtual Server Monitor Analyse Plan Enforce Shared Knowledge Operating System Open Virtualization Format Platform as a Service Quality of Service Representational State Transfer Red Hat Enterprise Linux Return of Investment Round Robin Public Final Version 1.0, March 29 th

6 SaaS SLA SLO SMI SOA SRC SRPT USDL VM WLC WP WRR WS WSGI WUI XML XMPP Software as a Service Service Level Agreement Service Level Objective Service Measurement Index Service-oriented Architecture Source Shortest-remaining-processing-time Unified Service Description Language Virtual Machine Weighted Least-Connections scheduling Work Package Weighted Round Robin Web Service Web Server Gateway Interface Web User Interface extensible Markup Language extensible Messaging and Presence Protocol Public Final version 1.0, March 29 th

7 1. Introduction 1.1. Context and objectives The main goal of MODAClouds is to deliver methods, a Decision Support System (DSS) and an open source IDE and run-time environment for the high-level design, early prototyping, semi-automatic code generation, and automatic deployment of applications on multi-clouds with guaranteed QoS. The MODAClouds Consortium The present document is Deliverable 6.1 Analysis of the state of the art and defining the scope (henceforth referred to as D6.1) of the MODAClouds project. The main objectives of this document is to analyse the state of the art regarding cloud monitoring, management APIs, automatic deployment and run-time performance models, and to establish the general requirements that will define the scope of the MODAClouds project. Figure 1.1.a depicts the methodology followed to define the requirements presented in D6.1. In order to collect the requirements that will drive the development of the MODAClouds framework, the following steps have been carried out: i. Collection and structured review of the relevant State of the Art; ii. Elicitation of requirements from (i); and iii. Prioritization of the requirements. State of the art analysis Elicitate Requiements Prioritize Requirements Figure 1.1.a. The MODAClouds requirements elicitation.. We have carried out an extended review of the State of the Art in the following research fields covered by MODAClouds in order to identify gaps, deficiencies, needs and problems, and thus elicit requirements: Run-time platforms for cloud environments; Monitoring cloud infrastructures and applications; Quality of service in cloud-based environments. The QoS metrics of interest in this deliverable are identical to the ones reviewed in D5.1 for the design-time evaluation. Thus, they are mainly concerned with quantifying application responsiveness, scalability, and dependability. We point to D5.1 for an extensive description. The state of the art analysis is based on an initial search in the major research databases of computer science, i.e. ACM Digital Library, IEEE Xplore, SpringerLink, ScienceDirect and Google Scholar using keywords such as Cloud computing, multiclouds, risk, quality management, interoperability, architectures, deployment, monitoring, etc. We gave priority to publications dated from 2007 (as according to Google Trends search and news reference volume data the term Cloud computing started becoming popular in 2007 [GT13]) untill February However, older references are used when necessary. From these papers, references were checked and additional papers were found. Initiatives coming from standardization bodies, leading vendors and funded projects were also included in this survey. This resulted in a collection of several hundred publications that included (a) conference, workshop and symposium papers, (b) journal articles, (c) electronic articles and (d) technical reports and white papers. Around 200 publications were finally selected as the most relevant. Public Final Version 1.0, March 29 th

8 1.2. MODAClouds Run-Time Environment Vision Before presenting the analysis of the state of the art, in this subsection we describe the overall goals of the runtime environment, we describe the general approach and the high-level conceptual architecture. With this we aim at providing a general framework to discuss self-adaptive architecture. This also provides relevant information that might be useful when discussing monitoring platforms and reviewing existing QoS management solutions Goals and Technical Assumptions MODAClouds aims at defining a runtime environment specifically tailored to the execution of applications developed with its design-time tools. The high-level objectives of the MODAClouds runtime environment are several and can be summarized as follows: 1. Define a monitoring platform to characterize the state of applications developed and deployed using MODAClouds. 2. Define self-adaptive policies to manage application QoS at runtime. These policies will rely on models, shipped with the runtime environment, to perform predictions on application performance and scalability as well as to track or estimate its current status and resource demands. 3. Develop an execution platform for managing application deployment, configuration, and run-time execution. This platform will be utilized by the self-adaptive policies to manage application QoS. 4. Define data synchronization and load balancing mechanisms to support the execution of an application that is replicated over multiple clouds to ensure high-availability. The above goals are quite broad and therefore require clarifying more precisely the scope. The main underlying technical assumptions of the runtime environment that will be adopted are as follows: Supported application classes. For an application developed with the MODAClouds design-time methodology, the runtime environment will offer its functionalities on the supported IaaS and PaaS platforms. For these applications, the run-time environment aims at maximizing automation, while still keeping the human in the loop, especially in situations when this is highly-desirable, for example incident management. We will focus on Linux applications, with a specific emphasis on applications running inside the Java virtual machine. Extension to other application classes will be evaluated and defined after the requirement phase for the main case studies is completed. Single-Cloud Deployment. MODAClouds will support public cloud deployments where an application is entirely deployed on a given IaaS platform or entirely deployed on a given PaaS platform. The choice of the target platform is delegated to the software developer, which should base this choice on the MODAClouds decision support system. Multi-Cloud Deployment. MODAClouds applications may require the simultaneous deployment on two cloud platforms or two different availability zones in order to guarantee continuous availability in face of a cloud outage. In the context of the runtime environment, we therefore need to ensure that the failure of a cloud platform A will not result into unavailability also for the backup copy deployed on cloud platform B. Based on this observation, we will assume that the two applications will have independent runtime environments. A special-purpose software component will be developed to ensure that upon a failure of one of the two platforms, the incoming application traffic can be gracefully redirected to the other platform. Data will be replicated on the two clouds and the runtime environment will offer a mechanism based on streams to synchronize the data across clouds and therefore optimise the downtime. Notice that the migration process underlying the deployment of an application running on cloud A onto a new cloud B is intended as process that will be fully done at design-time, it is not intended as code movement or live migration. The only migration operation that will be performed at runtime is the data synchronization that will be used to migrate the data. Application Deployment and Execution. MODAClouds will manage the execution of applications on a set of target IaaS and PaaS public clouds. To avoid making the scientific and technical approach of the runtime environment too dependent on the target clouds chosen, we intend to use the work done in the mosaic and in the Cloud4SOA FP7 projects as a starting point for defining the MODAClouds runtime execution platform. In particular, we intend to reuse part of the execution mechanisms implemented in mosaic for IaaS platforms, and in Cloud4SOA for PaaS platforms, to manage the MODAClouds application lifecycle (e.g., application Public Final version 1.0, March 29 th

9 start/stop/initial configuration/etc). This will provide a runtime environment that exploits and enhances technical outputs of recent FP7 projects, thus leveraging code maturity and avoiding solving issues already addressed by other EU projects. Application-Oriented. The MODAClouds runtime will allow to monitor and adapt the deployment of a cloud application with the goal of meeting the QoS goals decided at design-time. This will require operating in parallel to the application a number of software services, controllers, and tools that will be instrumental to achieve this goal. However, as part of the runtime environment, these systems will consume themselves physical resources and, in line of principle, may be subject to their own set of QoS and cost constraints. In general, to avoid an excessive complexity in the design of the runtime and to avoid focusing on secondary aspects, these concerns will be treated as minor compared to the QoS and cost constraints specified by the developer for the running application. Legacy software. The runtime environment will also provide the ability to execute applications shipped with legacy software components. One example could be a legacy business logic written in C++. However, limitations may apply on the ability of the framework to automate all the operations for these applications. Therefore, a substantially higher level of involvement of human administrators for management could be required in this case. Monitoring approach. The monitoring approach adopted in MODAClouds is focused on addressing the needs of all stakeholders involved in the operation and management of cloud applications. In particular, it aims at satisfying the following important requirements: i) be able to collect data at various levels, starting from the hypervisor level, when exposed by the cloud platform, up to the application level; ii) be able to cope with the case of single-cloud and multi-cloud deployments; iii) be extensible in terms of the information to be collected and of the filtering and correlation actions to be performed on such data. In order to address the last point, the architecture of the monitoring approach will be highly composable and will allow for the installation of special purpose data collectors, in charge of acquiring data depending on the needs of the stakeholders interested in performing monitoring, and data analysers. Moreover, it will feature a proper language to support different kinds of filtering and composition of the acquired information MAPE-K Loop The overall paradigm adopted by the MODAClouds runtime environment is inspired by the research area of Autonomic Computing, which has greatly increased over the course of the last ten years the common understanding on how to realize systems with self-managing capabilities. The MODAClouds runtime is inspired in its high-level design by the MAPE-K loop, which is one key conceptual aspect of the Autonomic Computing field. The MAPE-K autonomic loop (Monitor, Analyze, Plan, Execute, Knowledge) represents a blueprint for the design of autonomic systems where a managed element is coordinated by a loop structured in 4 phases and a common knowledge (see Figure 1.2.a). Public Final Version 1.0, March 29 th

10 Figure 1.2.a: MAPE-K loop The MAPE-K loop is structured in 4 consecutive phases: Monitoring. The monitoring component is responsible for managing the different sensors that provide information regarding the performance of the system. In the MODAClouds context for example, sensors can capture the current consumption of critical node resources (such CPU and memory) but also other performance metrics (such as the number of processed requests in a time window and the request process latency). The monitoring granularity is specified by rules. Sensors can also raise notifications when changes to the system configuration happen. Analysis. The analysis component is responsible for processing the information captured by the monitoring component and to generate high level events. For instance, it may combine the values of CPU and memory utilization to signal an overload condition in the platform. Planning. The planning component is responsible for selecting the actions that need to be applied in order to correct some deviation from the desired operational envelope. The planning component relies on a high level policy that describes an adaptation plan for the system. These policies may be described, for example, using Event Condition Action (ECA) rules that are defined by a high level language. A ECA rule describes for a specific event and a given condition what action should be executed. In the context of MODAClouds, the actions may affect the deployed artifacts and the bindings among these ones. Execution. The execution component applies the actions selected by the planning component to the target components. Additionally, the shared knowledge includes information to support the remaining components. In the context of MODAClouds, it maintains information about managed elements. Overall, a model of the MAPE management processes within the context of a generalized system management meta-model also developed within few relevant projects like Auto-I [AUT13], ANA [ANA13], or CASCADAS [CAS13]. In addition, the topic is analysed by Calinescu, with the meanings of formal methods [GPA13] Conceptual Architecture The MAPE-K loop only represents a design blueprint that leaves lower level details of the architecture purposely unspecified (i.e., they do not impose constraints on the implementation). In these initial months of the project, the MODAClouds consortium has defined a reference conceptual architecture for the runtime platform which we here describe and that follows the MAPE-K loop design approach. The details and implementation of this conceptual architecture will be specified more in the details in follow up Year 1 deliverables which will iterate on this initial description to produce a concrete implementation plan. The goal of this section is to provide a Public Final version 1.0, March 29 th

11 high-level intuition of the systems that will compose the architecture, which is required in order to identify the actors that are involved in the requirement specification. Figure 1.2.b: Conceptual architecture of MODAClouds runtime environment Figure 1.2.b shows the main components of the MODAClouds runtime platform. We here consider a runtimecentric perspective and therefore, the runtime subsystems are exploded, while the design time systems are left as a single component (the MODAClouds IDE). More in details, the runtime environment will be composed of three main platforms: 1. The monitoring platform responsible for data collection, analysis, and definition of summary measures (application health, QoS, etc). This platform will be in charge of collecting information from various sources (cloud monitoring interface, application-level components, PaaS containers) and filtering, correlating, and analysing such information with the purpose of executing a set of monitoring rules that will be defined by the design-time tools provided by MODAClouds. For example, a monitoring rule could check every 60 seconds in a time window of 3600 seconds if response time is greater than 1 sec more than a given number of times. The violation of such rules determines the triggering of actions in the self-adaptation platform. 2. The self-adaptation platform. This subsystem is responsible for state tracking of the currently deployed application and for the decision-making to identify changes in the current configuration of the cloud-based application to satisfy with SLA requirements. The self-adaptation platform is activated by the monitoring platform in response to some alarming event or performs predefined analyses periodically without being explicitly triggered by the monitoring platform. The self-adaptation platform will be developed jointly across WP4 and WP6, the former focusing more on the underlying software engineering aspects (e.g., the Models@Runtime approach described in deliverable D4.1), while the latter will focuses more on the runtime reasoning. We point to deliverable D4.1 for a description the self-adaptive platform and we focus here only on specifying its requirements that do not overlap with those in D The execution platform. The execution platform provisions all services that are needed to deploy on the clouds both the application and the corresponding monitoring platform. The initial deployment decisions are initially provided by the MODAClouds IDE and translated to the target platform. The execution platform also offers the services and the API needed to maintain and change the operational state of the deployment at runtime, typically under triggers of the self-adaptation platform. Public Final Version 1.0, March 29 th

12 Each platform has therefore a clearly identified role and will interact with the other platforms, whenever possible, via RESTful services or data streams that will hide implementation details. This will allow the runtime platform to integrate more easily contributions written in different languages and styles Overview The rest of the document is divided into four sections: Section 2 presents a description of the state-of-the-art on run-time platforms for cloud environments, specifically those handling the execution and deployment of applications. With this section we aim at analysing tools that could potentially be used to create the run-time MODAClouds environment. Section 3 describes previous work on monitoring cloud infrastructures and applications. This is an important aspect in order to be able to analyse the system and evaluate its performance in different regards. Section 4 reviews methods proposed during the last decade to provide tools to system administrators to manage QoS of online applications. QoS is essential for the optimal delivery of cloud services. Finally, Section 5 presents the use cases and the requirements of the platform. Public Final version 1.0, March 29 th

13 2. State-of-the-Art: Run-Time Platforms 2.1. Preamble The purpose of the current section is to highlight the potential solutions that could be used to develop MODAClouds run-time environment, specifically those handling the execution and deployment of applications. Thus the technical solutions surveyed herein, are grouped in the following broad categories: PaaS --- solutions featuring an integrated application and required services or resources life-cycle --- from packaging, through deployment, execution and monitoring --- available usually as hosted services from various cloud providers; deployment and execution --- independent software artifacts that focus mostly on the deployment and execution phases; these could be seen as lightweight PaaS replacements, especially suitable for applications requiring a more conservative environment, such as customized software packages, full access to the OS or the network, etc.; deployment only --- similar with the above but focusing only on the deployment aspects, such as installation and configuration; This survey is structured as follows: we start with a section (Criteria) describing the characteristics and capabilities we are interested to find in the proposed solutions; then in the next one (Solutions) we systematically take the exponents from the categories mentioned earlier, and for each one we provide the following information: o the "Overview" section presenting a very high level picture, together with a small dictionary describing the terms either unique or having a particular interpretation in the solution's context; also if needed an architectural view, or short descriptions of various important mechanisms; o the "Criteria" section, summarizing characteristics pertaining to the surveyed solution; this should be materialized in a highly structured text, such as lists or tables; o followed by the "Notes" and "Limitations" sections that should provide a subjective --- from the MODAClouds perspective --- critique of the proposed solution, highlighting advantages, disadvantages, future developments, and if possible comparisons with other solutions in the same category; o then a short "MODAClouds integration" section that would highlight how would the project benefit by integrating the proposed solution; o and last a "References" section pertaining solely to the analyzed solution --- those references pertaining to multiple solutions should be placed in the proper global references section; However before proceeding we must make a few observations about the purpose of these solutions, and the distinction between the user's application, and the MODAClouds services supporting that application. Therefore: in the context of the following sections by application we understand the user's application; that is the software artifacts written and provided by the user himself which implement the desired functionality, plus the required services or resources, such as databases, middleware or other generic components, that are required by the user's components; such an application could target either a PaaS or IaaS cloud provider; however in order to enhance the user's application with features such as monitoring, QoS enforcement, automatic scalability, or cloud migration, we are required to run certain support services alongside the user's application; unfortunately due to the complexity and requirements of such support services, we are uncertain that they would be able to run inside a PaaS, as such it is our intention to run these on a IaaS alongside the PaaS that hosts the user's application; (for a IaaS-only solution things are much simpler;) we focus on the deployment and execution solutions for the user's application; although we keep an eye open for the possibility to manage alongside the application also the support services; but as stated this is not a main requirement; moreover the current survey assesses only the technical aspects related with deployment and execution, meanwhile other parts of this deliverable tackle individual traits such as QoS, monitoring or loadbalancing; non-technical aspects such as cost and pricing models are discussed in deliverable D2.1; Public Final Version 1.0, March 29 th

14 we reiterate once more that, except the "Overview" section, the other sections of the survey are a subjective take on the solutions, the perspective being that of the MODAClouds own focus and requirements; Criteria Although many of the surveyed, or other existing, solutions are production-ready --- or even better backed up by powerful companies in the IT sector --- and offer many features, we must focus our effort in determining if they are a good match with MODAClouds requirements, described in a later section. Such a goal implies two separate conditions: first of all they should be suitable for our industrial partners' case study applications; which in turn implies matching the supported programming languages, palette of available resources and middleware, and nonetheless security requirements; and in order to fulfill our project's goal, they must provide a certain flexibility, to allow our run-time environment to integrate, and provide support for the user's application; Therefore, we are especially interested in the following aspects --- due to space constraints, the possible values are described in Appendix A: type Actually one of the categories mentioned in the beginning of the section, which broadly describes what is the purpose of the solution and the range of features it offers. suitability Shortly, how mature, or production ready, is the solution? Does it have a supportive community built around it? application domain What would be the "main flavour" of targeted applications? application architecture Broadly matching a targeted application architecture. application restrictions What constraints would the application (and part of our run-time environment) be subjected to? programming languages and programming frameworks Some solutions target (or at least are focused on) a particular framework (such as Servlets for Google App Engine's Java environment, Capistrano tightly focused on Ruby on Rails deployment, etc.). Thus it would prove useful to know in advanced which are the officially sanctioned or preferred frameworks. scalability How can scalability be achieved? session affinity Usually PaaSs offer HTTP request routers (or dispatchers); how does they load-balance clients between the multiple available service instances? (How each client is identified depends on the internals of the PaaS and it could range from source IP address to cookies.) interaction How can we pragmatically interact with the proposed solution? hosting type How would we be able to use the proposed solution? portability If a developer uses a particular solution, how easy is for him to move to another solution having the same role? services Public Final version 1.0, March 29 th

15 Especially in the case of PaaS, what additional resources or services (such as databases, middleware, etc.) are available and managed directly by the solution, and thus integrated with the application life-cycle? monitoring coverage Especially in the case of PaaS, how much do the monitoring facilities cover and expose to the operator? monitoring level From which perspective, or at which level of the software and infrastructure stack, are the metrics provided? monitoring interface What technique --- such as standard, API, library, etc. --- is used to expose the monitoring information to the operator? Resource providers Most of the PaaS do not also have their own hardware resources, but instead are built on top of other publicly accessible IaaS providers. Thus if the user needs services not offered by the PaaS itself, it could use that IaaS to host the missing functionality himself. multi-tenancy This characteristic pertains mainly to PaaS or PaaS-like solutions, and tries to assess if multiple applications can share the same instance of the PaaS. resource sharing This characteristic pertains mainly to PaaS or PaaS-like solutions, and tries to assess how are the application components or services mapped on the provisioned VMs. limitations Most of the solutions impose quantitative limitations (such as memory, bandwidth, storage, etc.) on the running applications, which could be of interest especially in determining the suitability for our case studies Deployment Approaches PaaS solutions In the following subsections we survey the most important PaaS solutions, either hosted, like Heroku or Windows Azure, either deployable on self-provisioned IaaS, such as Cloud Foundry. Although there are countless other technologies fitting inside the PaaS category, especially emerging products from various startups, we have limited our survey to the ones most likely to be used inside MODAClouds, because they provide a wide degree of flexibility, or are popular choices amongst developers. Moreover this list is not exclusive, because if during the implementation phase of the project we find other suitable candidates we can use them as well Heroku Overview Heroku is a classical PaaS solution, featuring a large degree of flexibility for the targeted application, ranging from the largest set of supported programming languages, to the availability of third party integrated services. What it sets it apart from other PaaS solutions is the simplicity of developing and deploying applications that target this platform, the only requirement being to respect the "general accepted best practices", as summarized in [HER1] and detailed in [HER11]. For example while Google App Engine requires the developer to choose exactly one of the three supported languages, then to strictly adhere to a reduced API and use Google's customized data stores, in contrast Heroku allows the developer to run almost any "well behaved" web Public Final Version 1.0, March 29 th

16 application, and exposes access to resources ranging from the classical SQL databases to distributed search indexes. Regarding the tooling, the deployment is almost completely driven via the Git distributed versioning system, but at the same time there are CLI tools --- based on web services --- that allow full control of the application. Characteristics type PaaS suitability production application domain web applications [HER1] application architecture n-tier applications [HER1] application restrictions container [HER2] programming languages Ruby, Python, NodeJS, Java [HER3] programming frameworks any scalability manual [HER4] session affinity non-deterministic [HER7] interaction WUI, CLI, WS, API [HER9] hosting type hosted portability out-of-the-box services large palette of managed services [HER6] monitoring coverage none (however there are add-ons) backing provider Amazon EC2 [HER2] Limitations OS resources: memory per dyno 512 MB (soft-limit) and 1.5 GB (hard-limit) [HER2] disk per dyno unspecified CPUs per dyno unspecified package size 200 MB [HER8] [HER10] Networking accessibility: inbound HTTP exclusively [HER7] [HER10] outbound allowed (with exceptions) internal disallowed [HER10] Notes Although Heroku has official support for some programming languages, it can support practically any application that can be run on Linux, via their "buildpack" feature [HER5]. As above, out-of-the-box Heroku does not provide any type of monitoring --- except for the existence of processes --- but there are various third party add-ons available that monitor the running application from within. Unfortunately even with these add-ons we cannot get any data from "within" the platform. With regard to the network accessibility, for inbound network connections only HTTP --- for the domain under which the application was registered --- is forwarded to the processes with the web type, while any other access from the exterior does not seem to be supported; on the other hand, it is hinted that the HTTP router does support the CONNECT verb --- a unique feature among existing PaaS solutions --- enabling thus the proxying of arbitrary protocols. For outbound connections it seems that there are not any constraints except the "best practice" policies, and the fact that the source IP address might change at any time. The connections between various processes, thus internal, seem to be disallowed [HER10]. (The documentation is not definitive in any of these regards, especially about the existence of any quota.) The cost seems to be higher when compared with VMs (with higher capacity) from the underlying provider (Amazon), and especially when using add-ons. On the positive side, for each application there is an amount of free time which would allow a user to run a single process for a month (or multiple processes for a fraction of a month). Public Final version 1.0, March 29 th

17 MODAClouds integration Heroku provides unique possibilities, not found in other commercial PaaS solutions, for integration with MODAClouds. We could provide customized "buildpacks" [HER5] that would augment the user's application code with our probes, without impacting his development, packaging and deployment experience. Moreover, because Heroku allows the user to run multiple types of processes, and because we can customize the deployment, we could run the support services that MODAClouds needs directly inside the same application instance. On the other hand, because the platform itself is hosted over Amazon EC2, we could easily deploy our services there. Finally, the API exposed by Heroku [HER9], although simple, it allows fine grained control over the application, from changing the number of instances of a certain process type, to attaching add-ons or accessing logs Cloud Foundry Overview At a high level Cloud Foundry can be also seen as part of the classical PaaS family, similarly to Heroku. Cloud Foundry allows the developer to run almost any "conventional" application without changes --- one that uses the most common frameworks and respects the common "best practices" --- also providing support for the most common resources (such as relational databases). Two important highlights of Cloud Foundry are the fact that its source code is released under an open-source license, and that there is a "Micro Cloud Foundry" [CFY4] solution that enables the developer to have a local deployment and testing environment that simulates the hosted platform. Because Cloud Foundry is at the same time both a hosted PaaS (by VMWare), and an open-source product, in this survey we focus especially on the hosted platform, because many of these limitations and constraints depend solely on the choices made by the hosting provider; meanwhile the open-source variant allows anyone that wants to deploy it, to add support for new programming languages, services or raise limitations. Unfortunately unlike Heroku it is not ready for production yet, allowing only limited resources to the applications, providing a very small set of additional resources or services, and constraining the supported programming languages and frameworks. However, compared with Heroku and other PaaS solutions, regarding the possible application architectures and the HTTP routing layer, it promises to offer more flexibility. To sum up. Cloud Foundry offers three different forms of a PaaS: CloudFoundry.com: Public instance of the open Cloud Foundry PaaS operated by VMWare. CloudFoundry.com is now in beta and can be used for free. Micro Cloud Foundry: Complete Cloud Foundry instance contained within a virtual machine. This product is intended to be installed directly in a developer s computer in order to simulate the interaction with a real cloud foundry-based private or public cloud with the same environment, ensuring that applications that run locally will run in the cloud too. Cloudfoundry.org: Open Source project hosting the Cloud Foundry technology. With the tools within this project a private PaaS can be built and deployed on top of any IaaS. Different configurations can be built, achieving different supported languages, frameworks and application services. Characteristics type PaaS suitability emerging application domain web applications application architecture 2-tier applications (but see the notes) application restrictions container programming languages Java, Ruby, NodeJS [CFY3] programming frameworks popular frameworks (Spring, Java Servlets, Rails) plus "standalone" Public Final Version 1.0, March 29 th

18 scalability manual session affinity sticky-sessions [CFY1] interaction CLI, WS, API hosting type hosted, simulated, deployable open-source portability out-of-the-box services MySQL, PostgreSQL, MongoDB, Redis, RabbitMQ [CFY2] monitoring coverage basic monitoring level container backing provider VMWare (private solution) Limitations OS resources: memory 2 GB [CFY1] disk 2 GB [CFY1] descriptors 256 [CFY1] CPUs 4 [CFY1] Networking accessibility: inbound HTTP exclusively outbound allowed (with exceptions) [CFY1] internal unspecified Notes Much that can be said about Cloud Foundry was already written in the overview above, and could be summarized as: it could be considered as an alternative to Heroku; its major advantage over the other PaaS solutions is its open-source license; there is a solution that offers the developer an "emulator" of the hosted platform that can be run on a local machine; overall it is a promising solution, but currently it is still in beta status; Regarding the support of programming languages and supported frameworks, it is more strict than Heroku: only the available ones can be used, and there is not an option to customize the build and packaging process (without the developers intervention). The limitations are clearly described, and on par with Heroku. Unfortunately, due to its current beta status, it cannot host any real world application, because all the applications (or application instances) summed total memory cannot be over 2 GB [CFY1], and there does not seem to be support for domain names others than *.cloudfoundry.com. Moreover, the limitation on file descriptors of 256 could be worrying, because it implies that each instance cannot have more than 256 concurrent HTTP requests, which for real-time web-applications (such as using web-sockets) would be a show-stopper. Although the deployed applications must fit the 2-tier model (i.e. monolithic process and database or middleware layer), Cloud Foundry has a unique feature that allows different applications to share the same services or resources, thus allowing the user to obtain a n-tier model by splitting his application in multiple ones when deploying to Cloud Foundry. MODAClouds integration Again we stress the fact that the following statements apply mainly to the hosted solution (by VMWare), because in a self-deployed Cloud Foundry environment the operator has many other choices. From MODAClouds perspective, Cloud Foundry currently has less to offer than Heroku, as it has the following major disadvantages, especially when thinking about how to run the additional support services that MODAClouds require: Public Final version 1.0, March 29 th

19 it is backed by VMWare IaaS solution (presumably VMWare vsphere), but in a private cloud; this implies that we will not be able to provision any VM for our support services, that would be able to interact with the running application; currently the supported services and resources is a very small set, and there is not any (practical and cost effective) way to add others; the limitation imposed on the applications --- the total amount of memory used by the entire application is only 2 GB --- makes it difficult for any real world application to be run; the limited number of programming languages imposes large restrictions on what services we are able to effectively use; On the positive side it does offer some advantages, although marginal compared with the drawbacks: it does provide basic monitoring information (memory, CPU, disk) at instance level; it allows the user to upgrade the application without interrupting the service --- through manipulation of the HTTP routes, and only if the old and new versions of the application are capable of handling it; But all in all we could still manage to use it as a run-time platform for the applications, provided that we host the support services in another provider, not without performance degradation or cost increases AppFog Overview AppFog is one of the commercial PaaS solutions that have been built upon the open-source licensed Cloud Foundry code base. AppFog is limited in a similarly to Cloud Foundry, hosted by VMWare. As such in the current section we shall focus mainly on what is different than in the case of Cloud Foundry. Characteristics type PaaS suitability production application domain web applications application architecture 2-tier applications application restrictions container programming languages Java, Ruby, Python, NodeJS, PHP [APF2] [APF4] programming frameworks popular frameworks plus "standalone" scalability manual session affinity sticky-sessions (presumably) interaction WUI, CLI, WS, API hosting type hosted portability out-of-the-box services MySQL, PostgreSQL, MongoDB, Redis, RabbitMQ [APF3] [APF4] monitoring coverage basic monitoring level container backing provider Amazon, HP [APF4] Notes and Limitations Most are presumably the same as in the case of Cloud Foundry --- there is not a clear documentation stating the constraints --- with the following notable exceptions: the limit of 2 GB total memory for an application can be raised if the user pays; however the user can create an unlimited number of applications for free, within that 2 GB limit; Public Final Version 1.0, March 29 th

20 there is a way to access some resources (like the relational databases) backing the applications [APF5]; it is backed by public IaaS offerings; MODAClouds integration As stated in the introduction AppFog inherits some of the drawbacks of Cloud Foundry, especially when compared with Heroku. For example the number of programming languages is slightly larger than with Cloud Foundry, but we cannot run arbitrary applications as we can in Heroku. However, because AppFog is backed by Amazon and other public cloud providers, we have the ability to deploy our support services on VMs residing in the same cloud. Moreover through the "tunneling" feature [APF5] we could support the migration of the application data, at least for the limited set of supported resources AWS Elastic Beanstalk Overview In order to ease the deployment of applications over its IaaS solution, Amazon provides a simple wrapper service, namely AWS Elastic Beanstalk, which given a deployable software artifact --- either in compiled form, or source code, depending on the target platform --- automates the following aspects of the application life-cycle: [ABS1] provisioning the required VMs from EC2, with the right image needed for the targeted run-time; configuring both the VM related aspects, like security groups, but also the complementary required services, like AWS Elastic Load Balancer, or AWS CloudWatch; deploying the software artifact inside the run-time environment; managing complementary services like the Elastic Load Balancer solution; Concepts: application An umbrella concept for all the entities that belong to the same logical "application". version A deployable software artifact, suitable for deployment. Each application can have at any time multiple versions, each prepared for immediate execution, thus enabling the operator to rollback to previous versions if a particular deployment manifests issues. [ABS4] environment The run-time instance of a particular version, again there can be multiple concurrent environments, possibly of the same version. The environment also specifies the characteristics of the VM to be deployed on. [ABS4] resources Any external database, middleware, etc., that the application needs, and which is completely out of the control of the platform (although the various web-based wizards, do allow the operator to create an Elastic Load Balancer or an RDS instance). Characteristics type application deployment and execution suitability emerging application domain web applications application architecture 2-tier applications application restrictions none programming languages Java, PHP, Python, Ruby,.Net [ABS1] programming frameworks a selected set, specific to each supported language [ABS1] scalability none (delegated to AWS Auto Scaling) session affinity none (delegated to AWS Elastic Load Balancer) interaction WUI, CLI, WS, API hosting type hosted portability out-of-the-box Public Final version 1.0, March 29 th