CloudLaunch: Discover and Deploy Cloud Applications

Cloud computing is a common platform for delivering software to end users. However, the process of making complex-to-deploy applications available across different cloud providers requires isolated and uncoordinated application-specific solutions, often locking-in developers to a particular cloud provider. Here, we present the CloudLaunch application as a uniform platform for discovering and deploying applications for different cloud providers. CloudLaunch allows arbitrary applications to be added to a catalog with each application having its own customizable user interface and control over the launch process, while preserving cloud-agnosticism so that authors can easily make their applications available on multiple clouds with minimal effort. It then provides a uniform interface for launching available applications by end users across different cloud providers. Architecture details are presented along with examples of different deployable applications that highlight architectural features.

💡 Research Summary

CloudLaunch is presented as a unified platform that enables discovery, cataloguing, and deployment of scientific and general‑purpose applications across multiple Infrastructure‑as‑a‑Service (IaaS) clouds. The authors begin by outlining the problem of vendor lock‑in and the fragmented, provider‑specific solutions that currently dominate cloud‑based software delivery. To address this, they design a system consisting of three logical layers: a web‑based front‑end, a RESTful back‑end, and a pair of plug‑in interfaces (front‑end and back‑end) that encapsulate application‑specific logic.

The front‑end is built as a single‑page Angular application written in TypeScript. Each application that can be launched is represented by a front‑end plug‑in that extends a BasePluginComponent. The plug‑in supplies a JSON schema describing the configuration parameters required for that application (e.g., VM size, storage volume, security groups) and renders a dynamic form for the user. This design allows highly heterogeneous applications—from a simple virtual machine to a complex virtual laboratory such as GVL—to be presented through a consistent UI while still exposing the necessary custom options.

The back‑end is implemented with Django and the Django‑REST‑Framework, exposing four top‑level endpoints: applications, infrastructure, deployments, and authentication. The infrastructure endpoint mirrors the CloudBridge library’s abstraction over cloud provider APIs, providing a uniform view of compute, storage, networking, and security resources for any supported provider (AWS, Google Cloud, OpenStack, etc.). The applications endpoint stores metadata about each catalogued appliance, including a reference to the specific back‑end plug‑in that knows how to launch it. Deployments are recorded with details such as the target cloud, launch parameters, and runtime outputs (IP address, URL, etc.).

Deployment requests are processed asynchronously via Celery task queues. When a user initiates a launch, the front‑end sends the JSON configuration to the back‑end, which loads the appropriate back‑end plug‑in. The plug‑in’s launch method may perform any sequence of actions: create a VM, attach block storage, configure firewalls, or invoke external automation tools such as Ansible. The plug‑in also implements three management actions—health_check, restart, and delete—allowing the same API to monitor and control running instances. Because the plug‑in code is pure Python and interacts with CloudBridge rather than provider‑specific SDKs, the same plug‑in can be reused across clouds without modification, eliminating the need for per‑provider testing.

A key contribution of CloudLaunch is its emphasis on open, well‑documented standards. The REST API is self‑describing and browsable, the configuration payloads are JSON, and the CloudBridge library is distributed as an independent pip‑installable package. This makes it straightforward for external scientific gateways or workflow systems to integrate CloudLaunch as a deployment engine without pulling in the entire web UI.

The authors compare CloudLaunch to existing vendor marketplaces (AWS Marketplace, Google Launcher, etc.), noting that those services provide proprietary “recipes” tied to a single cloud and require users to search multiple catalogs to find the same application on different providers. In contrast, CloudLaunch offers a single catalog and a uniform launch workflow, dramatically simplifying the user experience and reducing the operational burden on application developers.

Limitations are acknowledged. CloudLaunch deliberately does not manage the runtime lifecycle of deployed applications—features such as auto‑scaling, dynamic reconfiguration, or persistent storage management are left to external orchestration layers. Moreover, the system assumes that required machine images and data are already available on each target cloud; developers must either replicate these assets manually or adopt containerization strategies to achieve true portability. The paper mentions future work to support the TOSCA standard, which would enable declarative, portable application descriptors and further automate multi‑cloud deployments.

In summary, CloudLaunch provides a modular, plug‑in‑driven deployment engine that abstracts away provider‑specific APIs, offers a consistent user interface, and supports both manual and programmatic (API) usage. Its architecture—separating UI, API, and per‑application logic—facilitates rapid addition of new applications and easy integration with other scientific gateways. While it currently focuses on the provisioning phase, its design lays a solid foundation for future extensions into full lifecycle management and standards‑based orchestration, making it a valuable tool for research institutions and enterprises seeking to avoid vendor lock‑in while leveraging multiple cloud infrastructures.