Cloud Application Management Framework

Primary tabs

The project aims to develop and sustain the necessary tooling that will assist Cloud application lifecycle management operations, using open standards and languages, where appropriate. As aforementioned, these operations are classified into three distinct categories: (1) application description, (2) application deployment and (3) application monitoring. CAMF will follow the Eclipse OSGi plug-in based software architecture for each of the aforementioned operations and will inherit the same look-and-feel that Eclipse users are accustomed to. To guarantee the quality of the resulting product, the project will follow designated development cycles with rigorous code reviews, unit tests and release cycles.

The Cloud Application Project

Cloud Application Project Figure

Figure 1 - The Cloud Application Project view.

 

Similar to other Eclipse frameworks, CAMF organizes all the files related to a Cloud application in a structured hierarchy that utilizes the Eclipse file system (see Figure 1). A Cloud Application project, acts as a placeholder for a single application and any of its runtime dependencies. To this extend it provides containers (folders) for:

  • Application Descriptions; containing application structure blueprints described using the TOSCA open specification.
  • Application Deployments; containing important historical details (past and current) about application deployments to various IaaS. Among other, these include date/time, the particular IaaS, reference to a particular version of the application description, operational costs, etc.
  • Artifacts; containing artifacts required for the deployment and correct operation of the Cloud Application such as executable files and/or third-party libraries, custom virtual machine images, Chef configuration and deployment scripts, SSH keys etc.
  • Monitoring Data; containing users' custom monitoring probes. These probes interface with the underlying monitoring system and obtain information that report the runtime health and performance of the application.

Also each project is associated with one or more IaaS-provider profile, that contains important information for interfacing and utilizing/querying the offered resources of each provider. Such information include communication endpoints, authentication credentials, granted permissions and rights, etc. which are manually provided by the user or wizard-imported from a standardized format input file.

Cloud Application Description

Cloud Application Description

Figure 2 - The Cloud Application Management Framework User Interface while describing a 3-Tier Web-based video streaming service.

 

OASIS TOSCA open standard provides a language for describing the structure of Cloud applications, along with their management operations. The structure of an application presents its principal components and defines any existing relationship among them. Such components are described in TOSCA by means of Nodes and are used to represent specific types of executing entities in a deployment (i.e. an application component can be a Tomcat application server in a 3-tier web application). Each Node can have certain semantics such as: (i) Requirements against its hosting environment, (ii) the Capabilities it offers and (iii) the Policies that govern its execution such as resource security or elasticity. Similarly, as the name suggests Relationships represent the associations among Nodes and have their semantics based on their individual type. TOSCA provides the necessary grammar to describe management aspects of an application by means of lifecycle operations or by more complex Management Plans. For each Node its lifecycle operations can be defined, (i.e deploy or start an instance of the corresponding Node Type).

Nevertheless, compiling TOSCA documents (XML content) manually is cumbersome and quite error-prone endeavor. CAMF's Application Modeling Tool (see Figure 2), enables the compilation of large and complex TOSCA-based application descriptions, simply by following through a users' graphical input. The Application Modeling Tool associates all TOSCA elements with visual elements (available via a Palette view) that are consequently used to model an application schematically. All graphical interactions with available visual elements (drag'n'drop, move, delete, etc.) are translated on the fly into TOSCA XML content by considering the semantics of each underlying utilized element. Inherent compilation complexities are hidden from the user and possible errors that can be introduced via non-valid graphical actions are avoided/minimized using various visual cues and textual warnings. Moreover, continuous checks are performed on the generated TOSCA XML content to assure conformance with the standard. To facilitate the above, CAMF utilizes and improves upon the capabilities provided by the Graphiti graphics framework, for generating state-of-art diagrams for particular domain models.

The Palette View (see Figure 2, right-hand side) acts as a front-end to a Cloud Information System for visually representing all the resources available by one or more IaaS. The Cloud Information System provides a vendor-agnostic model for storing fundamental resource metadata that can be utilized during the application description and deployment processes. Among other these resource metadata include handles to: available public/private VM images and corresponding flavors, available software packages, Chef recipes, application-level and resource-level monitoring probes, etc. Using the jclouds toolkit, metadata are retrieved from each IaaS "marketplace" once during the creation of an IaaS-specific profile (endpoint and credential provision), and are consequently refreshed on intelligently adapted time intervals. In addition, the Palette View can display information about local resources, included/added by the user in Cloud Application Project hierarchy. Finally, to minimize the information displayed and swiftly identify any required component, the Palette includes standard searching and filtering mechanisms.

Cloud Application Deployment

Cloud Application Deployment

Figure 3 - The Application deployment view, showing the status of the application on Amazon AWS EC2 and an OpenStack-compliant IaaS.

 

The TOSCA description along with the artifacts realizing all management operations of a particular application are packaged into a single fully self-contained archive, called Cloud Service Archive (CSAR). In case of a TOSCA-compliant provider, CAMF enables the submission of CSARs to a dedicated endpoint so as to be processed and interpreted accordingly by a TOSCA runtime environment, such as the one implemented in OpenTOSCA. According to the specification, Cloud providers that wish to become TOSCA-compliant should provide a Container entity as part of their Cloud architecture (see Figure 4). This entity is responsible to communicate with an IaaS orchestrator to make the necessary IaaS-specific operations to satisfy the respective TOSCA description.

Application Deployment Process

 

Figure 4 - Exemplary Application Deployment Process at TOSCA-compliant Cloud providers.

 

In case that a Cloud provider is not yet TOSCA-compliant, CAMF adheres with the standard by providing the necessary abstractions and extension points for the implementation of TOSCA containers at the tools's side. These are jclouds-based connectors for specific IaaS, which can be easily developed following other exemplary implementations, or installed (if available) from a public p2 repository. In such scenarios, the application description generated by the Application Modeling Tool, is consequently parsed locally by the implemented connector responsible to execute IaaS-specific API calls for deployment and runtime configuration of the particular Cloud application.

 

Cloud Application Monitoring

After deployment, the application developer can interact with the Deployment View (see lower part Figure 3), so as to obtain instantly the deployment status without leaving the Eclipse environment. The Deployment view provides a snapshot of all application deployments grouped per target IaaS. Each deployment is accompanied with provider-specific properties such as component IP addresses, instance IDs, running times etc. A background polling mechanism refreshes the view and tries to always provides the latest information from each IaaS. Finally, c-Eclipse provides interfaces so as to be integrated with existing monitoring systems, enabling thus its users to monitor the performance of their deployed applications from a single environment. Currently, it is fully integrated with the JCatascopia Cloud monitoring system, nevertheless JCatascopia is not a CAMF dependency and thus can be swapped with another Cloud monitoring system.

Contribution Activity: 
Commits on this project (last 12 months).