Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

In recent years, as an answer to market demands, Cloud Computing has experienced a growth in goals and capabilities [14]. In this quick evolution of the technology, vendors have developed their own cloud solutions by providing different approaches, where different functionalities are provided by different APIs following diverse business models. In fact, as a consequence of this heterogeneity, cloud developers will often be locked-in specific services from cloud providers, since many interoperability and portability restrictions are found when different vendors’ solutions want to be used.

Recent proposals, like those in [9, 11, 13], take advantage of new advances in the management of topologies of applications that have been deployed on cloud to solve most of the interoperability issues related to application deployment. Among these emerging solutions, we find platforms with the capability of allowing developers to find the best alternative for the deployment of each component of their applications. The last step in this direction is the possibility of deploying applications combining services from IaaS and PaaS levels, possibly by different vendors in trans-cloud environments [6]. In fact, as we can see in, e.g., [1, 5, 12], the decision of what vendor or service level to use to distribute the components during an application deployment is not trivial. It is indeed a challenge, because of the multitude of cloud offerings. Migration of individual components or entire applications may indeed be unavoidable over time, because of changes in the offered services, prices, security policies, or simply because a provider just stops providing its services. Once developers can take advantage of the features of different kinds of services, they will be interested as well in optimizing the cloud resources usage and improve their applications’ performance.

If component deployment reconfiguration is a complex task, doing it at runtime, trying to minimize down times is even more challenging. Migration is still an unresolved topic which has been widespread studied by both academia and industry (see, e.g., [10, 16]). To migrate some components of a running cloud application, it is necessary to orchestrate the entire cloud context, such as services and bound resources, to reach the expected movement of the components services but taking into account the possible interoperability and portability problems. In fact, migration opens a lot of new key issues related to cloud resources, application components, and their management. We can find several proposals (see, e.g., [2, 3, 8]) on the live migration of cloud application’s components, focusing on the movement of running application components between different vendors. However, these solutions focus with one service level (cf. [3, 8, 15]).

In [7] we proposed an orchestration algorithm to migrate a single application’s stateless component between different providers in an agnostic way, what means that it is not bound to any service level, either IaaS or PaaS, of any particular provider. In this new proposal we go one step further and extend the aforementioned tool by proposing a new algorithm to reach the component-wise migration of entire applications. Since the migration of components with state pose additional difficulties, we only consider stateless components. The algorithm performs the migration in parallel and agnostically, by moving just the necessary application’s components to respective target services, independently of the target providers and abstraction levels, either IaaS or PaaS.

This extension is built over trans-cloud concepts [6]. Specifically, the solution in [6] uses the TOSCA standard to model agnostic applications’ topologies, which do not use any specifics of the target providers over which they will be deployed. The information related to the cloud service level, IaaS or PaaS, is added by means of a policy-based mechanism independent of the topology description. The trans-cloud environment processes these specifications and uses an homogenization API, which unifies IaaS and PaaS services of different vendors, to orchestrate the deployment over the required cloud services.

By relying on the trans-cloud infrastructure operations such as stop, re-start, move and re-connect are used on the necessary components independently of the service level, IaaS or PaaS, the cloud technology or any other dependencies. The algorithm receives a set of components of an application that has to be migrated and their target locations. It operates on the application’s components following concurrent policies, working in parallel.

The rest of this paper is structured as follows. Preliminaries about trans-cloud deployment and its current implementation are presented in Sect. 2. The proposed migration algorithm for stateless components is described in Sect. 3. Details on the implementation of the algorithm are presented in Sect. 4, together with some experimental results. Finally, Sect. 5 conclude the paper and presents some plans for future work.

2 An Overview of Trans-Cloud

In this section we provide an overview of trans-cloud and its main capabilities. These concepts are illustrated with a running case study, which will be later used to show the use of the our proposal in Sect. 3 and to evaluate it in Sect. 4.

2.1 A Trans-Cloud Environment

Trans-cloud significantly reduces the portability and interoperability related issues. It allows developers to deploy their application by using available vendors’ services and resources, at IaaS or PaaS levels, releasing them from the usual infrastructure limitations while defining their applications. The trans-cloud approach relies on three main ideas: agnostic topology descriptions, target services specifications, and a unified API.

For the agnostic specification of applications’ topologies we use the TOSCA standard,Footnote 1 which allows us to provide full-detailed specifications of application components, how they are inter-related and their respective configurations. To manage the selected cloud services to deploy applications’ components, we use Apache Brooklyn, which defines a common interface for the homogeneous treatment of different cloud vendors and their services.

The description of target services needs a mechanism to agnostically specify the target cloud services which will be managed from the Unified API. To do this, we use locations, which represent cloud services on which to perform the deployment, both for IaaS and PaaS services. As we will see in the coming sections, locations are defined independently of the topologies, what allows us to change target services just by changing the corresponding locations.

The trans-cloud tool presented in [6] builds on the Brooklyn-TOSCA open project for enabling an independent specification of the used services, and on the Apache Brooklyn project to provide a common API for the unified management of IaaS and PaaS services. Figure 1 shows an overview of the proposal in [6]. A description of how the extension of Brooklyn was carried out to support PaaS providers can be found in [7].

Fig. 1.
figure 1

Trans-Cloud approach

Full size image

Although the current official release of Brooklyn only handles IaaS services, as can be seen in Fig. 1, Brooklyn’s API was extended in [6] with new mechanisms for the management of PaaS services. Our extension takes advantage of the genericity and flexibility of Brooklyn’s API, which has the independency between application descriptions and cloud services used in their operation as one of its goals. Initially, CloudFoundry-based platforms, like Pivotal Web Services, IBM Bluemix, etc., were integrated, to prototype the PaaS support, and to allow components to be deployed using both IaaS and PaaS.

As we will see in the following section, the trans-cloud approach provides a set of useful basic mechanisms to build an agnostic algorithm to reach the migration of application’s component. Application components are specified in an agnostic way and their control, with operations like stopping, restarting, starting in a new location, can be delegated to the aforementioned unified API, which handles any application component independently of the kind of service where it will be running, either IaaS and PaaS.

Fig. 2.
figure 2

Brooklyn-TOSCA Softcare’s topology

Full size image

2.2 The Softcare Case Study

Softcare is an application for the social inclusion of elderly people and for the management of their medical problems. The application, developed by originally developed at Atos [4], is a cloud-based clinical, educational, and social application, based on state-of-the-art technology.

As depicted in Fig. 2, the application is composed of seven modules: four web modules over respective Tomcat servers (note the Tomcat icons), and three MySQL databases (note the database icons). The SoftcareDashboard component provides the main graphical user interface, and depends on the Forum, Multimedia and SoftcareWS modules. Forum adds a forum service to the web platform, Multimedia is responsible for managing the offered multimedia content, and SoftcareWS contains the application’s business logic. The databases ForumDB, MultimediaDB and SoftcareDB store, respectively, the forum’s messages, the multimedia content, and the rest of the application’s data.

Given a TOSCA YAML description with the appropriate location specification, the Brooklyn system will create suitable entities to manipulate each module. Listing 1.1 shows a Softcare’s TOSCA YAML topology schema, where just some elements are described to illustrate the agnostic-based application description. We can see how this mechanism allows the separation between topology description and the providers specification. In lines 29–37, we see that the components are deployed on AWS (Ireland’s cluster) and SoftLayer (London’s cluster), both of them IaaS services.

figure a

If we used the TOSCA YAML in Listing 1.2 instead, the components that were targeting SoftLayer would now be deployed on Pivotal (PaaS). The only change between these YAMLs is the target location for some of the modules, with no modification on the original topology or the description of the components.

figure b

3 Migration Algorithm

Our migration algorithm, specified in Algorithm 1, is completely agnostic, it is just a process orchestrator. Given the abstractions provided by the trans-cloud management tool, and the way application, components and their relations are modeled and handled by it, the migration algorithm is reduced to a minimum. Thus, the management of each concrete application component and bound cloud resource can be delegated to a generic API which hides the complexity of managing different cloud providers. For example, the stop(component) operation is in charge of stopping a component regardless of where it is running, either on an IaaS or PaaS service, and the resources it is using.

figure c

The migration algorithm is in charge of providing a thread-based parallelized operational plan for the migration of each stateless component to the specified target locations. To minimize waiting times, the algorithm follows a distributed approach. Decisions are made on a component basis, so that each component checks its own dependencies and moves forward in its specific task as soon as possible. The algorithm simultaneously operates on all specified components by following a multithreaded strategy, controlled by the application of a set of rules to detect dependencies between component and cloud resources, and then ensuring the integrity of the application during the migration process.

During the execution of the algorithm, we differentiate two phases: the stop phase, where all necessary components—components to be migrated and all other components depending on them—are stopped and cloud resources are released, and the start phase, where affected components are re-deployed in desired locations, stopped components are re-started, and connections are re-established. To maximize concurrency during these phases, actions on components are bundled on tasks, namely, STOP_TASK (lines 16–28) and START_TASK (lines 30–45). For example, a task for stopping a component will contain the necessary operations to stop the component and release its resources. Once a set of tasks have been generated, they will be executed in parallel using the parallelExecution() operation of the executor object.

The operation MIGRATE(a,cls) takes as inputs an in-memory representation of an application’s topology, a, and a map cls that associates to each of the components of the application to be migrated its target location. The set of keys of this map (cls.keys()) represents the components to be migrated.

Before migrating a component, it is necessary to stop all its input dependencies. For example, if we wanted to migrate a back-end server, which is being used by a set of front-end components, we should ensure that all the components connected to the back-end have been stopped beforehand. The stop phase of the algorithm proceeds recursively on the ancestors of each component of the application (parents(a,component)), starting with the set of components with no dependencies in the set of components to stop (findComponentsWithNoDeps(a,cls) in line 6), which results in a top-down strategy. Given stop tasks for each of the components in the hierarchy, the concurrent executor will launch each of them in parallel. The stopping task on a component concludes with the invocation of either the stopAndReleaseResources(component) (line 24) or the stop(component) (line 26) operations, depending on whether the component in question is one of the components to be migrated or not. These two operations belongs to the trans-cloud API, and will take care of the specificities of the providers and services used. The only difference between them relies on the releasing of the resources used. Those components to be migrated will have new resources bound, and the stopAndReleaseResources operation is used on them.

Once all necessary components have been stopped, the target components have to be re-deployed in the new locations. Then, all stopped components, those migrated and their ancestors, must also be either started or re-started. In this phase, if a component has all its dependencies fulfilled (checked by the isReadyToStart(component) operation, line 32), the following stand-up operations are applied to it: (1) start/re-start, (2) re-establishment of its connections, and, finally, (3) re-start of its ancestors. The recursive invocation to the ancestors re-starting results in a bottom-up traversing strategy on the dependency structure, which means that a component will only be re-started after all its input dependencies are satisfied. This procedure ensures the topology’s integrity and avoid unexpected behavior during the migration. If a specific component has not migrated, it just need to be re-started using the services already bound. If it is one to be migrated, it will be started on the new target location. In both cases, the task concludes re-establishing the relations of the component. Again, all these operations are performed with invocations to the trans-cloud API.

4 The Tool in Practice

In this section, we briefly illustrate how our trans-cloud approach can be used to deploy the application’s components on different services simultaneously, and how the migration algorithm can be applied to move some of these components to the specified target locations. We use the Softcare case study introduced in Sect. 2.2 to illustrate the tool and its use. The implementation and the rest of the documentation are available at github, from https://github.com/scenic-uma/brooklyn-dist/tree/trans-cloud-app-migration.

Fig. 3.
figure 3

Deployment of the Softcare application using its TOSCA specification

Full size image

4.1 Application Deployment

Our extension of Brooklyn adds to Brooklyn the required mechanisms to support the deployment of components on PaaS vendors, following the trans-cloud concepts. We focus here on the use of Brooklyn-TOSCA and how, thanks to the Brooklyn’s plugin, our proposal supports TOSCA-based topology descriptions to be managed by the extended Brooklyn.

In order to deploy an application using our trans-cloud tool, first we need to provide a TOSCA-based topology specification, with all the details on the application topology, its components and how they are related, their properties, configurations, etc. Then, since the trans-cloud mechanisms have been totally integrated under the API in the customized Brooklyn version, we may use the default Brooklyn Web ConsoleFootnote 2 to deploy our applications using their TOSCA YAML descriptions. For example, given the complete TOSCA YAML description of the case study presented in Sect. 2.2 (an excerpt with its structure is given in Listing 1.1), we may use Brooklyn’s Web Console to deploy the Softcare application on AWS EC2 and SoftLayer as shows the snapshot in Fig. 3.

Once the TOSCA YAML is loaded in Brooklyn’s Blueprint Composer, we may click on the deploy button. If so, the topology is processed by the extended Brooklyn (by means of Brooklyn-TOSCA) and the application is deployed using the selected cloud services and resources, AWS EC2 Oregon’s Cluster and Softlayer London’s Cluster.

4.2 Migration Request

As explained in previous sections, the extended version of Brooklyn provides support for the component-wise migration of applications. Precisely, the migration may operate on as many stateless components of an application as desired. Although the migration algorithm was developed as an independent orchestrator, since it is included in the customized Brooklyn, we may now apply the migration process to any application which has been deployed (and is therefore being managed) by Brooklyn. Moreover, by the agnosticity of our TOSCA-based application descriptions, we may migrate then without any changes on the application topologies or their descriptions.

Continuing with our case study, and assuming that the Software application has previously been deployed as indicated in the previous section, we explain here how the application can be migrated. Precisely, we show how some of its stateless components, namely SoftcareDashboard and Forum, are moved to different services. To perform the component-wise migration of an application we must just provide the target locations of the components to be migrated. We could, of course, change the location of all the components of an application. Here we migrate just two of them: SoftcareDashboard is moved from SoftLayer’s datacenter in London to Amazon EC2, and Forum is moved from Amazon EC2 to Pivotal Web Services. Notice that whilst the first migration involves two IaaS providers, the Forum component is moved from IaaS to PaaS.

Fig. 4.
figure 4

Migration process launch

Full size image

Thus, the algorithm just requires a map associating the components to be migrated to the target locations. These locations are selected from a catalog of available datacenters. Figure 4 shows a snapshot of the Brooklyn Web Console with the pop-up window to specify the migration to execute. We can see on the left a tree with the Softcare components running as deployed in the cloud as deployed in the previous section. At the center of the figure we can see the pop-up window with the invocation of the migration process. As value the migration task receives the map configuration with the desired location targets.

Once the map with the target locations has been provided, the migration algorithm is executed by clicking on the Invoke button. The algorithm is applied according to its specification in Sect. 3. First, Forum is selected to be stopped. The stop operation on SoftcareDashboard is suspended, since it is a direct ancestor of Forum. Thus, the algorithm first tries to stop the Forum component, but since its ancestors must be stopped before, the SoftcareDashboard is then stooped. Once SoftcareDashboard is not running, Forum is stopped. Because both SoftcareDashboard and Forum are to be migrated, every bound cloud resources are also released. Then, the re-start process begins. The SoftcareDashboard component cannot start directly, because one of its dependencies (Forum) is not ready. Hence, Forum is started first on pivotal-ws. Finally, once Forum has been re-deployed and all its relations have been re-established, SoftcareDashboard is deployed on AWS. After each start and re-start operation, all necessary relations are re-established to maintain the expected application behavior.

5 Conclusions

An agnostic algorithm to orchestrate the migration process for the stateless component of applications in cloud environments have been proposed. The algorithm allows the parallel migration of several components of an application, and it only needs the mapping of components to be migrated to new locations, independently of the service level (IaaS or PaaS) used both in the source and the target provider. This is possible because the algorithm is based on trans-cloud mechanisms also provided as part of this work. Thus, the proposed algorithm is vendor, technology and service-level agnostic. The migration process is fully automated, and is available on an extended version of Apache Brooklyn. The only required external intervention to carry out the migration is just a migration request to initialize the process.

As future work, we plan to extend our algorithm in several ways, in particular to optimize downtimes. The current version of the algorithm is based on first stopping the components to be migrated, and then starting or re-starting them. To minimize the downtimes we will re-engineer the definitions of lifecycles in Brooklyn to allow the deployment and starting of migrated components before stopping then.