CloudLaunch: Discover and deploy cloud applications

https://doi.org/10.1016/j.future.2018.04.037Get rights and content

Highlights

  • Present CloudLaunch as a platform for discovering and launching cloud applications.

  • CloudLaunch uniformly supports multiple cloud providers.

  • Arbitrary applications can be added via open technologies.

Abstract

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.

Introduction

As cloud technologies and platforms become more mature, modern Infrastructure-as-a-Service (IaaS) clouds are broadly converging in terms of functionality and scope [1]. Nevertheless, as others have noted elsewhere [2], subtle differences in providers can easily lead to vendor lock-in. This is a significant problem in both academic and commercial settings, where heterogeneity in resource access, funding models, and geography can make it difficult to share cloud applications developed in one setting, with cloud infrastructure running in a different setting. As clouds increasingly become the de facto means of software delivery to end-users, it becomes just as important to support multiple cloud infrastructures operated by different vendors and communities.

There has been a proliferation of private and community clouds; in the academic community, there are a number of national-scale academic community clouds including, the NeCTAR cloud in Australia, the ELIXIR cloud in Europe, the Jetstream cloud [3] in the US, the CLIMB cloud [4] in the UK, and efforts in Canada, South Africa, and others. Many vendors have emerged in the commercial space with some stable big providers such as Amazon, Google, and Microsoft.

Users tend to be generally tied to whatever cloud infrastructure their hosting company or funding model allows them access, or on whichever cloud their data happens to reside. Despite the potential promise of ubiquitous cloud access, the reality is that users are often siloed within their institutional cloud, with no way to marry software available on a particular cloud, with the data and resources they have access to in their institutional cloud.

As a result, the burden increasingly falls upon cloud application developers to make their applications available on multiple clouds. This is somewhat analogous to how desktop application developers must support different operating systems to reach their target audiences. This requires that the developer:

  • 1.

    Build and test their application against multiple clouds;

  • 2.

    Provide a means by which a user can discover and launch an application on a cloud infrastructure of their choice;

  • 3.

    Ensure that the application is orchestrated, monitored, and managed on the target infrastructure.

In previous work on CloudBridge [1], we addressed the first issue, noting that many existing solutions to the problem, such as Apache Libcloud [5] and Ansible [6], do not provide a unified abstraction for IaaS clouds, requiring that developers test their applications against individual cloud infrastructures. It is only at a level higher that containerization frameworks such as Kubernetes and Docker Swarm have alleviated this problem somewhat by letting developers deal with a Platform-as-a-Service (PaaS) level of abstraction.

In this paper, we discuss our work in addressing the second aspect of this problem, building upon previous work done in BioCloudCentral [7]. For this purpose, we built CloudLaunch — a web portal and an API platform for discovering and launching applications on multiple cloud infrastructures. Novelties introduced by CloudLaunch include the ability to describe an application once using open technologies and have it uniformly deployable on multiple cloud infrastructure providers using a web interface or a REST API. With the API driven approach, CloudLaunch can be used as a deployment engine for external applications to provide cloud abstraction and orchestration capabilities. In this context, we identify at least four potential beneficiaries of the CloudLaunch science gateway:

  • 1.

    End users who want to easily discover and launch applications on multiple clouds;

  • 2.

    Application deployers who want to make applications available on multiple clouds through CloudLaunch’s centralized catalog;

  • 3.

    Application developers who need an API-driven deployment engine to use within a custom application, say for constructing a higher-level science gateway;

  • 4.

    Institutions that want to have their own catalog of applications for internal users.

Section snippets

An overview of CloudLaunch

For an end-user, the initial entry-point to CloudLaunch is a web interface for browsing a catalog of appliances (Fig. 1 A). An appliance represents a deployable system, which can be as simple as an operating system running on a virtual machine or as complex as a virtual laboratory (e.g., GVL [8]). A key benefit of an appliance is that it comes with ‘batteries included’ — it provides the necessary infrastructure, applications, and configurations to deliver a functional system to the user. Next,

Architecture

The design of CloudLaunch is focused on flexibility and extensibility. By flexibility, we mean the ability to support a range of usage scenarios. This can mean usage via the web frontend or the API as well as the ability to integrate with a variety of infrastructure providers or applications. While we focus on deploying applications to IaaS cloud infrastructures here, the application is designed such that appliances can be launched on other infrastructures as well, for example cloud container

Demonstrations

To showcase the described features of CloudLaunch, we have implemented a number of appliance plugins. These include an appliance for launching a simple VM with a base operating system, launching an arbitrary container from Docker Hub, a complex virtual lab deployment, and several more as combinations thereof. These can be explored and launched from a live instance of CloudLaunch available at https://launch.usegalaxy.org/. Instead of using a public server, CloudLaunch can be deployed locally

Related work

CloudLaunch sits on the intersection of application deployment tools and a cloud API. Application deployment actions involve provisioning, management, and configuration of resources to make them suitable for application execution. Tools such as Ansible [6], Chef [17], Puppet [18], and SaltStack (see [19] for a comprehensive review) perform these tasks well and represent a suite of configuration management tools, with each having a slightly different approach to state and resource management.

Conclusions and future work

As an increasing number of application become cloud-enabled, it is desirable to enable application developers and deployers to make the given applications available for launching on a variety of clouds without requiring duplicate effort. Similarly, end users should be able to discover available applications and deploy those on a cloud to which they have access while using a consistent interface. With these aims in mind, we developed and presented CloudLaunch as a web application and an API

Acknowledgments

This project was supported by the National Human Genome Research Institute[grant number 5U41HG006620-06], National Cancer Institute[grant number CA184826], National eCollaboration Tools and Resources[grant number VLS402], Australian National Data Service[grant number eRIC07], and the European Regional Development Fund [grant number KK.01.1.1.01.0009].

Enis Afgan is a research scientist in the Taylor Lab at Johns Hopkins University. He obtained his Ph.D. in 2009 from the Department of Computer and Information Sciences at the University of Alabama at Birmingham. His research interests focus around distributed computing, with emphasis on utility of Cloud Computing resources. He currently works on the Galaxy Project (galaxyproject.org) with the goal of establishing scalable, comprehensive, and accessible data analysis environments using Cloud

References (23)

  • N. Goonasekera, A. Lonie, J. Taylor, E. Afgan, CloudBridge: A simple cross-cloud python library, in: ACM International...
  • BestavrosA. et al.

    Toward an open cloud marketplace: Vision and first steps

    IEEE Internet Comput.

    (2014)
  • C.A. Stewart, et al., Jetstream: A self-provisioned, scalable science and engineering cloud environment, in:...
  • GuestM.

    CLIMB, the Cloud Infrastructure for Microbial Bioinformatics: An online resource for the medical microbiology community

    Microb. Genom.

    (2016)
  • Apache, Apache libcloud, [Online]. Available: http://libcloud.apache.org/. (Accessed 1 January...
  • HallD.

    Ansible Configuration Management

    (2015)
  • AfganE. et al.

    Using cloud computing infrastructure with CloudBioLinux, CloudMan, and Galaxy

    Curr. Protoc. Bioinform.

    (2012)
  • AfganE.

    Genomics virtual laboratory: A practical bioinformatics workbench for the cloud

    PLoS One

    (2015)
  • AWS Marketplace: Homepage, [Online]. Available: https://aws.amazon.com/marketplace/. (Accessed: 26 April...
  • Cloud Launcher - Marketplace Solutions | Google Cloud Platform, [Online]. Available:...
  • McKayS.J. et al.

    Cloud computing with iPlant atmosphere

    Curr. Protoc. Bioinform.

    (2013)
  • Cited by (15)

    View all citing articles on Scopus

    Enis Afgan is a research scientist in the Taylor Lab at Johns Hopkins University. He obtained his Ph.D. in 2009 from the Department of Computer and Information Sciences at the University of Alabama at Birmingham. His research interests focus around distributed computing, with emphasis on utility of Cloud Computing resources. He currently works on the Galaxy Project (galaxyproject.org) with the goal of establishing scalable, comprehensive, and accessible data analysis environments using Cloud Computing resources.

    Andrew Lonie is director of Melbourne Bioinformatics (http://melbournebioinformatics.org.au), director of the EMBL Australia Bioinformatics Resource (EMBL-ABR: http://embl-abr.org.au), and an associate professor at the Faculty of Medicine, Dentistry and Health Sciences at the University of Melbourne, where he coordinates the M.Sc. (Bioinformatics) and leads the Genomics Virtual Laboratory program.

    James Taylor is the Ralph S. O’Connor Associate Professor of Biology and Associate Professor of Computer Science at Johns Hopkins University. He is one of the original developers of the Galaxy platform for data analysis, and his group continues to work on extending the Galaxy platform. His group also works on understanding genomic and epigenomic regulation of gene transcription through integrated analysis of functional genomic data. James received a Ph.D. in Computer Science from Penn State University.

    Nuwan Goonasekera is a research fellow at Melbourne Bioinformatics of the University of Melbourne. He obtained his Ph.D. in 2012 from the Faculty of Science and Engineering at the Queensland University of Technology in Brisbane, Australia. He currently works on the Genomics Virtual Lab (www.gvl.org.au).

    View full text