FluidCloud: An Open Framework for Relocation of Cloud Services Andy Edmonds Thijs Metsch Zurcher¨ Hochschule fur¨ Angewandte Wissenschaften Intel Ireland Limited Dana Petcu Erik Elmroth Jamie Marshall Institute e-Austria Timisoara Umea˚ University Prologue Plamen Ganchosov CloudSigma Abstract and automated. From this work a number of research and engineering challenges arise including data optimisation, Cloud computing delivers new levels of being connected, runtime architecture adaptation, and goal-oriented ser- instead of the once disconnected PC-type systems. The vice instance relocation. proposal in this paper extends that level of connectedness in the cloud such that cloud service instances, hosted by providers, can relocate between clouds. This is key in 2 A Problem in the Cloud? order to provide economical and regulatory benefits but more importantly liberation and positive market disrup- Cloud service instances remain locked under the control tion. of the service provider. FluidCloud will liberate these in- While service providers want to lock in their cus- stances. Having the ability for a cloud service instance to tomer’s services, FluidCloud wants the liberation of easily and seamlessly move from one provider to another those and thereby allow the service owner to freely will bring advantages and freedom to any cloud service choose the best matching provider at any time. In the owner. Essentially, it will bring service instance “move- cloud world of competing cloud standards and software ment rights” to the cloud. However there is no encom- solutions, each only partially complete, the central re- passing means to accomplish this. search question which this paper intends to answer: How FluidCloud fits within the soon future cloud. A rea- to intrinsically enable and fully automate relocation sonable view of this future cloud is the InterCloud. The of service instances between clouds? InterCloud is described in [2], [3], [4] where the gen- esis and progression of it from singular to multi-cloud ecosystems is stated. The concept of the InterCloud 1 Introduction is based on the proliferation and continued growth of public clouds ranging from Infrastructure as a Service Today, cloud computing [1] service instances cannot (IaaS), Platform as a Service and up to Software as a easily move from one cloud service provider to another. Service (SaaS). The ecosystem of these cloud service Cloud standards are seen to be the panacea, yet have little providers include the popular Amazon EC2, Rackspace, adoption by the market, especially by the market’s dom- and CloudSigma. inant players. Even when adopted, de jure standards are not as widely adopted as de facto standards (e.g. Amazon 2.1 The FluidCloud Concept EC2). Software libraries and frameworks that abstract cloud computing services to common interfaces are more Within the highly populated ecosystem of cloud service widely adopted (see “Related Work”). However, even the providers combined with the InterCloud concept, it be- most relevant standards or software libraries have little or comes crucial, both technically and financially, that ser- no service instance relocation functionality. Ultimately, vice instances can be relocated and consequently adapted those cloud service instances remain locked under the to their new service provider. In the vision of the Flu- control of the service provider, unless significant manual idCloud framework, the hosting cloud provider of the and/or ad hoc efforts are spent by the service instance service instance is not a concern anymore as the service owners. can be fluidly (easily, on-demand and dynamically) re- The proposed solution is the FluidCloud framework located between service providers. The FluidCloud con- which aims to make relocating services instances easier cept addresses multiple benefits: it will bring liberation 1 to cloud service developers and operators who own ser- and provisions a cloud service instance on the be- vices and are responsible for the associated data. They half of the service owner. Once that target service should have the option of movement for those services instance is provisioned the end-user interacts and instances, data and the efficient means to enable them. uses the target service instance, either through inter- It will enhance the InterCloud by advancing the defi- faces provided by the cloud broker or directly using nition (service topology), architecture and implementa- the interfaces of the provisioned target service in- tions of cloud computing, yet for stakeholders makes the stance. The cloud broker is aware of the end-users transition easy through the framework. It will make it service instances and can continually watch for more economical by suggesting new compatible service compatible service types that can be offered to the providers, based on economical differentiators. Regula- end-user as a replacement, based on economic/geo- tory obligations can dictate the geographical location of location/performance/feature/cost bases. If the ser- the service instance. If a running cloud service instance vice owner was interested the cloud broker can, us- is in an unrecognised or risky geographic region, the ser- ing FluidCloud, relocate the service on the owner’s vice provider can use FluidCloud to relocate that service behalf. instance at risk. Finally, with ease of relocation, posi- tive market disruption is introduced, with the market place opened further, enabling greater competition based 2.3 FluidCloud Contributions on service provider differentiation and not on technical lock-in or limitation is key. For such scenarios, as described above, to be technically realised there is a set of missing technologies. Fluid- Cloud fills these gaps by providing the following key 2.2 FluidCloud Scenarios contributions: To see how FluidCloud can be used in a practical sense, 1. Service Instance Relocation – Ensuring the over- consider some examples which demonstrate the need for all orchestration and process of moving a cloud the FluidCloud framework. service from the source to the target cloud service provider. There are two types of cloud services that • A Cloud Service Developer (CSD, e.g. Univer- FluidCloud will support and enable relocation for: sity startup). Take the example where a university IaaS and PaaS based services. The decision to re- startup implements a new service in the cloud. The locate will be initiated by the owner of the service type of service is one that is architected to han- (e.g. through a user interface or API). dle bursty traffic as described in [5]. After a pe- riod of time, the selected provider does not satisfy 2. Service Instance Adaptation - The conversion, from technical (e.g. provider outages), economical transformation and movement of the service and its (e.g. provider increasing prices), due to service of- related data. Related to relocating IaaS and PaaS fer changes. Here the benefits from a FluidCloud services are the potential service adaptations that concept is that the startup can easily relocate their need to take place. Parts of the service might need to service to a new cloud service provider. be adapted when relocated. For example virtual ma- • A Cloud Service Provider (CSP; e.g. CloudSigma, chines may need to be adapted (re-contextualised) ProfitBricks). A cloud service provider would like as its environment changes [6]. If we turn our atten- to relocate (or “on board”) new customers from tion to the PaaS area service instances need might other cloud service providers. What is needed is to need to be adopted (on source code level) for a cer- relocate new end-user service instances to their ser- tain target platform. vices from other, potentially, competing, differenti- ated services. This would allow the CSP to let their 3. Data Relocation - Relocation, migration, transfor- customers seamlessly relocate and adapt to their ser- mation and conversion of the data belonging to the vice offering. The cloud service provider operates service. Relocation of data fundamentally means the FluidCloud framework and offers it as a service. moving bits and bytes. Currently tools such as GlobusOnline provide a service for easily trans- • A Cloud Broker (e.g. CompatibleOne or Zimory). ferring data between Grid sites using the proven Developers and providers of cloud brokerage ser- GridFTP protocol [7]. Certainly technologies like vices and software should consider adding cloud Software Defined Networking can help when data service relocation functionality to their cloud bro- paths are needed on-demand to be established be- kerage offers. Typically, a cloud broker discovers tween two providers. 2 3 Architecture replacement provider the CloudConduit uses the Broker again to find suitable Migrators to aid the relocation pro- Core to realising FluidCloud are the following compo- cess. nents shown in the proposed logical architecture. Cloud service implementations are varied because their implementation can use IaaS or PaaS, for example. Therefore FluidCloud addresses: 1. Relocation of IaaS-based Service Instances. Fluid- Cloud will show the relocation of a service instance (and its data) running within virtual machines (on a local development machine, private end or public cloud). Triggers for the relocation can be scaling, costs, dependability or geo-location. The service instance will automatically be adapted to the new environment. 2. Relocation of PaaS-based Service Instances. The relocation of a PaaS based service instance and its Figure 1: Conceptual Architecture data between providers.