The parent subject matter of this paper is ultimately the cloud computing. ... cloud vendor servicing it all the time, but in addition gets a different cloud to be linked ...
International Journal of Innovative and Emerging Research in Engineering Volume 2, Issue 2, 2015 Available online at www.ijiere.com
International Journal of Innovative and Emerging Research in Engineering e-ISSN: 2394 - 3343
p-ISSN: 2394 - 5494
Interoperability in Cloud Federation: A Survey Bhavesh Jambaa, Prof. RajaniKanth Aluvalu b a
Student, Department of IT Engineering, School of Engineering, RK University, Rajkot, India Associate Proff. Department of Computer Engineering, School of Engineering, RK University, Rajkot, India
b
ABSTRACT: Cloud Federation, by definition is pooling resources together to provide a glitch-free access of resources to the users of the services offered to them by a cloud. [1] This paper revolves around in proximity to the computation practices. However, its highlight is cloud federation. This paper suggests a definition for the same term and before that, discusses the way computation was done by the mainframes, client/server applications and standalone clouds. It introduces cloud federation and then addresses the different approaches that can be practiced. At the end, the shortcomings of cloud federation are stated and this paper concludes. Keywords: Cloud Federation, Resource Sharing, SAML, SPML, OpenID, XMPP. I. BACKGROUND The parent subject matter of this paper is ultimately the cloud computing. But, before elaborating cloud computing, we intend to emphasize on cloud and computing individually. The roots lie within computing. In our yesteryears, (bulk) computing was defined by mainframes. [2] They were the ones that displayed the capabilities of surpassing humans in the calculation domain. Then came the client/servers, who became famous as better delivery agents for the computational tasks. These systems introduced balanced load handling to the computing world. [2] And, now we have cloud, which resides on resource sharing principles and more efficient computational systems. Cloud computing introduced a concept by which scaling was redefined to the business applications. [3]By its three very basic but sound implementation models, cloud made enterprise application and even general applications too more accessible to its users and the developers. The applications now resided centrally with its access and resource needs handled by a much smarter entity, known as the cloud. [3] In addition, the implementation models too were very neatly designed, so as to accommodate any application need which could be categorized easily amongst the business continuity, compliance or security domain. But, as time lapsed the technology transitioned from one horizon to another. Thus, mainframes were dipped by the client/server technology which in turn was displaced by the cloud as a priority. However, now the needs of the applications (in terms of resources for their regular function) are again saturating for the clouds to handle aptly. Mostly, it is the time factor that is to be addressed i.e. during peak hours of a day, even the clouds are not able to deliver as per their propound abilities. Hence, a suggestion for this particular issue; is cloud federation.[4][5] II. INTRODUCTION TO CLOUD FEDERATION Cloud federation according to this paper is defined to be a concept that leverages the capabilities of different clouds by unifying them as a single entity to prove to be a better, efficient and cost-constructive computational service. In reality, cloud is expected to exhibit indefinite resources to the application it hosts. But, depending on the (load) traffic, hardware and the network capabilities, there always existed a limitation in the catering of services by a cloud. Thus, the need for a federation is encountered. The emphasis is on the infrastructure provided as a service. [5] By federating clouds, an application has a primary cloud vendor servicing it all the time, but in addition gets a different cloud to be linked to it during the high requests time-zone. The participating enterprises are not responsible for managing the clouds infrastructure components and monitoring them thereafter. Service vendors do it for them. Resources and resource information besides the identities are the prime entities that transit amongst the federating clouds. Cloud Federation is of prime benefit to both the customers and the service vendors if implemented. [6] The customers would be viable to better throughput, day in and day out. While, the servicevendors would have a scalable or an extensible cloud to support several of the service offerings to its clients.
18
International Journal of Innovative and Emerging Research in Engineering Volume 2, Issue 2, 2015 A. APPROACHES TO CLOUD FEDERATION [7] a) Homogeneous Cloud Federation: The simplest of approaches, according to which one cloud would be federated to another by the service vendor whereby the participating enterprise would have no knowledge of it. And that is because, the enterprise is not responsible for the addition and migration of infrastructure related to its service. It’s the service vendor himself responsible for its management.
Figure 1. Homogeneous Cloud Federation b) Clouds use a set of communication protocols for transferring the information amongst them. These include SAML, WS-Federation, OAuth, XMPP, SPML, and OpenID to list a few. [7] XMPP – Extensible Messaging and Presence Protocol, as the name suggests is a protocol used to identify the clouds and communicate with them. SPML – Service Provisioning Markup Language, as the name suggests is a protocol used to provision and deprovision the resources to a cloud service[1]. In addition, it is also possible that more than a single cloud is federated to avail a cloud service. The reason is very obvious, to better load balance a high consumption service or to avoid the vendor lock-in issue. c) Heterogeneous Cloud Federation: An elongation of the homogeneous federation but with a facility to federate a public cloud with a private cloud. However, it should be noted that a public cloud cannot be federated to a private cloud but a private cloud can be federated to a public cloud. This federation here talked about is in relevance to the access i.e. private cloud can access a public cloud but a public cloud cannot access a private one.
Figure 2. Heterogeneous Cloud Federation d) Federation among applications on the same cloud: There may be applications that link to one another at a point of time. Mostly transactional applications fall into this category. It may happen that products may be displayed at a different service, they may be transacted at a different one and their payment may be performed by a different one. In addition, some centralized services also exist, like the one we have in Google providing a single sign-on to its each and every service. When these altogether different services reside on the same cloud, they can be federated to a single sign-on and better user experience.
e)
Figure 3. Federation among applications on the same cloud Federation among applications on different clouds: Very similar to the federation discussed above. But, the difference here would be, that the applications would now be residing over different clouds and they would be federated.
19
International Journal of Innovative and Emerging Research in Engineering Volume 2, Issue 2, 2015
Figure 4. Federation among applications on different clouds B. INTEROPERABILITY BETWEEN SERVICES PROVIDERS When an application is being designed, it is obvious that it will use any machine specific cloud library for its implementation and deployment. Moreover, by federating, the freedom a service vendor gets is - to attach an application to any desirable service provider i.e. a cloud. However, it should be noted that the implementation of the virtual machine that exists on that particular cloud which is being federated might be different from the one in which the application had been actually designed. Thus, the need arises for interoperability. [4][8] What interoperability offers is - a very clean application migration from one service provider to another. The application undergoes some very simple reconfiguration processes and no need exists to re-design the application for any target machine implementation due migration.[8]
-
-
III. SHORTCOMINGS IN FEDERATING CLOUDS Not every application can be deployed on the cloud. And, hence cannot be integrated with services to federate. Communication between services is important which requires a standard protocol. However, till date we don’t have a protocol that is standardized and communicates with every other federating service out there. Safe deprovisioning of the resources is a task to be given priority once the terms of usage a service expire. As identity of users reside on the cloud and if proper deprovisioning is not practised, security factor is compromised in federating clouds. [4] Billing and licensing is an altogether different task to be addressed. Special policies need to designed and mandated for proper functioning of the federating services. Cloud Storage and Computation services are always tightly coupled with a particular technology which cannot be altered or switched at a later time. This is defined as vendor lock-in. [4] Also, cloud computing is still in itself unexplored. Thus, the user is not sure of what issues he might face in the near future. Thus, while he is contracting on terms and conditions with any service provider for his application services, he is actually gambling on the technology. This is defined as the hold-up problem. [4]
IV. CONCLUSIONS Federating cloud computing is nowadays gaining pretty good momentum. There used to be a time when it was stated, just to be a potential next big thing in the computing sector. But, corporates have researched well enough and have moulded different protocols to talk to one another overtime. OpenID is one of them getting the most footage. However, it is yet not declared to be a de-facto standard for cloud federation. Cloud federation is a very valid concept and proves to befit affirmatively both the service vendors and the enterprises. Cloud Federation ultimately addresses the computation issues of an application or a service, besides scaling down its economic meter comprehensively.
REFERENCES [1] Tobias Kurze, Markus Klems, David Bermbach, Alexander Lenk, Stefan Tai and Marcel Kunze, “Cloud Federation”,Steinbuch Centre for Computing (SCC), Karlsruhe Institute of Technology (KIT), Available: www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf [2] Kanishk Mahajan, “Oracle Access Management Federation Service”, Dec 2013, Oracle Whitepaper, Available: http://www.oracle.com/technetwork/middleware/id-mgmt/identity-federation-wp-129458.pdf [3] Neha Mehrotra and Nitin Dangwal, “Interoperate in Cloud with Federation”, Infosys Whitepaper, Available: http://www.infosys.com/engineering-services/white-papers/Documents/interoperate-cloud-federation.pdf [4] George Demarest and Rex Wang, “Oracle Cloud Computing”, May 2010,Oracle Whitepaper, Available: http://www.oracle.com/us/technologies/cloud/oracle-cloud-computing-wp-076373.pdf [5] R. Harms and M. Yamartino, “The economics of the cloud”, November 2010, Microsoft Whitepaper, Available: http://www.microsoft.com/presspass/presskits/ cloud/docs/The-Economics-of-the-Cloud.pdf 20
International Journal of Innovative and Emerging Research in Engineering Volume 2, Issue 2, 2015 [6] Yvon Jegou, “Interoperability in Cloud Federations”, Available:http://www.futureinternet.eu/fileadmin/documents/aalborg_documents/S2_3_Interoperability/Yvon_Jegou.pdf [7] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “Above the clouds: A berkeley view of cloud computing”, University of California at Berkeley, February 10, 2009,Available: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf
21
