 I'm on. Hello everyone. I'm going to talk about Federation of OpenStack Clouds today. So before getting into the topic about myself, I'm a solution architect working at Cloud Enablers. My responsibility is mainly working on the cloud related products and programs in the organization. Now briefly talking about what we are going to discuss today. We will talk about Federation a bit. What is Federation and different approaches towards Federation. And next we will talk about there are certain projects that is going on certain projects and programs in OpenStack that actually is enabling Federation. How we can achieve a true Federation through various projects in OpenStack itself. And third we will talk about different use cases, basically the application of Federation in the real world, certain organizations or the companies they have implemented Federation. And third definitely I will be open to any kind of questions that you might have. So talking about Federation, different people have different versions or definitions of Federation but I tried to put it in a one liner. So Federation is basically a concept of bringing different providers, service providers across different platforms and the services provided by them for the end users consumption. So from the diagram it is obvious that Federation is bringing different cloud service providers together. Now what exactly Federation means to a provider. When you talk about provider definitely the main factor or main thing is for provider it can help in scaling up. What it means is capacity augmentation. In this dynamic world if there is a need for capacity definitely in a federated world a provider can add additional capacity with no time if a provider is under Federation. Second there is another way of looking at it if there is let's say capacity utilization in terms of optimum capacity utilization. Let's say a provider who is actually not having I mean utilizing its capacity, it doesn't have the customers but at the same region there is another provider who actually needs more capacity. So the capacity can be additional capacity can be given to the other provider by which actually it will be a optimum capacity utilization by both the providers or multiple providers. Then second interoperability. So today I think we have come to a stage where it is not only single resource consumption in cloud terms. I mean we are now talking about from resources to workloads. So it is a combination of resources in terms of forming a workload. So in that case the customers they are looking at different resources from different providers and combining them together as a workload and actually working on it. So that means we need to have interoperability provided to the end customer. Second what customer needs is a choice of services or catalog of services. He is not actually looking at only one provider having 10 different offerings. He is actually trying to do a lot of mix and match of services. He wants to explore different things, discover new offerings. It is not only need based but a lot of things are also getting discovered in due course of time by different providers. Now insight about providers and now how do we choose providers. Definitely we need to have some insight where we can select which provider is best suitable for me. These are couple of points towards federation. Now we will talk about the driving factors. I think we touched upon some of these points in the previous slides. Choice of providers. I mean we talked about it. Choice of providers definitely. How do I choose my providers? We cannot have let us say 5 or 10 providers listed and just simply you select this. I want this provider but because of what? What are the attributes of a provider we should look at? Is it the response SLA? It is the resolution SLA? It is the performance, the uptime or the SLA? I mean what is that or the location? What is the reliability of the provider? So there are various driving factors based on which customer actually is deciding today which provider he should go for. He should deploy his workload in. Mix and match of services. Definitely one provider is very good at SaaS. One provider is very good at something else. Maybe the compute someone is providing a best performing queuing services. So today the customer is looking at mixing and matching all those services provided by different providers and actually deploying its workload. Going local. So going local actually has two aspects. If you see why someone would look for localization. So definitely there are two factors today which drives going local. One is definitely the term we call data gravity. Data gravity means where the data resides. So if you take an example today there are a lot of e-commerce platforms evolving every day. So what does it mean is the e-commerce providers they want to be closer to their customers. If you see take an example of India or APEC region there are so many e-commerce providers. So they want to serve their customers from somewhere in India or APEC region at least in Asia. They are not comfortable in serving their customers from somewhere let's say a data center in US. Next is the user data gravity. Data gravity is something which again is related to this and I actually talked about data gravity. I will talk about user gravity. So these are the two factors which are actually deciding where the workloads should be. Where actually I should deploy my workloads. Now heterogeneity of platforms. Now this is something which is being talked about a lot whether it is open stack, cloud stack or any other cloud management platform or any other virtualization layer. Now customer would like to experiment and see which is best suitable for his workloads or his needs. So that is where heterogeneity of platform is one of the major driving factors which will actually enable true federation. Ability to scale. We talked about it so definitely in dynamic environment as of today we do not know what are our capacity needs. We can forecast only for a quarter or two but one year down the line how will be the demand for my workload or the resources I actually the customer is not able to predict today and that is why but whenever that happens they want to do it immediately. They should be able to add additional capacity without wasting much of time. Movement of migration of workloads. When we are providing choice of providers mix and match of services what it means is if a customer is not happy with one service provider how quickly is he getting logged in with one vendor or one service provider or he actually can migrate his workloads from one provider to another. If at all he do not actually he is not happy with one provider how easy or difficult it is to move his workload from one provider to another. So these are basically the driving factors which are actually going to accelerate federation. Now different approaches towards federation. The first approach what we are talking here is the so-called hybrid cloud approach. So if you we talk from a service provider's point of view suddenly he started with one data center in one region but slowly he is expanding its footprint across the globe and augmenting newer data centers. So what it means is definitely when something some resources has to be provisioned it cannot be that I should go to each and every cloud platform dashboard and I should provision the resources. So there is some kind of self-service portal which is actually targeted towards provisioning and the consolidated uses and metering aspect. So that is why this model came in. I mean this is I think there for the last couple of years. Similarly looking at the from the enterprise's perspective if we look at it they first tried to do something in-house or tried experimenting with the public cloud slowly either migrated into the hosted private cloud or on-premise private cloud or it is vice versa. From a private cloud they are going to public cloud. So this is one of the approach which actually is bringing federation but we cannot say this is a true federation in a sense. We will definitely come to the debate why this might not be the true federation. The second model if we see and maybe in the last three to four quarters we see a lot of traction gaining in the second type of federation which is marketplace based federation model where a user comes to a common marketplace where all the providers different providers are actually having real estate in terms of the different service offerings. So users come to marketplace, search, select, compare various services offered by different providers using different attributes. I mean as we discussed it can be SLA, it can be cost, it can be location, it can be geo, it can be anything. So when user comes and he selects again here he is mixing and matching the services. He selects one compute or the IS from one provider, a queue from another provider, a load balancer from some other provider. Now that is combined and packaged together and the cloud federation engine actually takes care of deploying the different or provisioning different resources across providers through this federation engine. So here if you see the federation engine and the cloud marketplace they are not related to any provider. So they are basically the provider and platform agnostic. So as and when the market is growing I think lot many cloud providers will come to this marketplace, join the marketplace. So user definitely, user gets all the benefits in terms of comparing different resources. He gets the best of available resources according to his need. Now but it is not only ending with the end user itself. Now this also provides an avenue for providers as well. Maybe it looks like providers are getting abstracted but actually that is not true. See once a provider comes to marketplace he gets to see like what other providers are offering in terms of the cost, in terms of performance. So this will actually give rise to a healthy competition among providers and definitely in that bargain what is going to happen at the end is this will also lead to lot of innovation. In terms of how can I optimize my cost? How can I provide the lowest compute or cheapest compute or resource, a cloud resource to my end user. So this will definitely give rise to lot of innovation. So that is where the benefits lies for the provider and of course they will get a 360 degree view of what others providers are offering in what cost. He should be able to compare himself with other providers in terms of what he needs to do or he is ahead in the market. So it actually this way I mean this is one of the model I mean we have seen the delts and IBMs of the world. So I think coming up with this marketplace based federation model in the last year and year half. So now I will actually talk about okay these are the two types of federation. What are the different projects available or going on any projects ongoing projects in OpenStack which is actually enabling this kind of federation. So definitely when we talk about federation first is when I have multiple providers how do I get into no two or three different providers? Do I need to have no individual identity or it is the same identity I can use? Definitely when it comes to the enterprises or end user they cannot have no identities across different for different providers they cannot maintain the credentials separately and an enterprise having different different users it again becomes even more complex. And that is where in the Ice House release OpenStack actually enabled identity federation through federated identity using Keystone. So I think all of us know about this. So now Keystone actually is acting as a service provider. So let us say any enterprise having its own corporate AD or LDAP or any other identity provider. So they need not to have their footprints in terms of credentials stored in Keystone. So Keystone would be able to take the authorization token and allow the users to consume any services across OpenStack. So this is actually really helped is helping lot of enterprises coming to OpenStack or any OpenStack related providers where they need not to again maintain the credentials. So this was a blocker and since Ice House release now this is something which is available. Now okay we come to OpenStack now that is good. So this was definitely one of the good thing that happened in the last release but having said that now we are talking about multiple OpenStack clouds. Now can it be possible let's say if I am already authenticated within by one Keystone will I be able to consume another OpenStack cloud by any other providers. So that again leads to the next actually enhancement in Kilo release which is basically Keystone to Keystone Federation. So in Keystone to Keystone Federation what actually is happening is two Keystones are acting as identity provider and service provider to each other. If a customer of cloud platform A is already authenticated by the Keystone A then Keystone for consuming any resources in Keystone B he did not to again enter its credentials. Those same authentication and authorization will be applicable. So there is a trust relationship that is getting built between two Keystones. Hence now it is becoming easy to consume resources across multiple cloud platforms. So this is one of the projects or initiatives from OpenStack which actually enables identity federation. So which is one of the aspect of the federated cloud model. Now we talked we saw we are able to login or get authenticated to different cloud platforms. Now once we get authenticated what we do next. Definitely we have to consume the resources. So what does it mean is we have to provision the resources or orchestrate resources across various cloud platforms. Now how does that happen. So in a typical or ideal federated cloud orchestrated model customer selects mix and match of services as we talked about VM, a virtual machine, a queuing service or a load balancer for let us say three different providers. On top of that customer wants monitoring any kind of management backup or DR service to be available for his workload. So the left hand side boxes what you see is the services that is provided by the different providers and on top of it in a marketplace model what is happening is a monitoring as a service or any kind of backup or DR as a service. Now that is being provided through the marketplace operator itself. Now all of that being packaged together is actually provisioned again through the federation engine and provisioned across different providers and the user get to consume it. Now this is one of the model okay this is an ideal model but how OpenStack can help us. So OpenStack the HEAT project which is well known for the orchestration I think a brief history about HEAT. HEAT initially started to support the AWS cloud formation template but over the period of time it has evolved as a robust orchestration engine and currently it supports hot template which is known as HEAT orchestration template. So whatever workloads we saw in the previous this thing if that can be templatized as a hot template and the HEAT orchestration engine what we are showing here is actually it is decoupled it is not tied to any specific OpenStack. If HEAT hot templates can be actually orchestrated across OpenStack clouds then this is possible and this is something which we have already tried in our lab and it is working fine. Now again the question next question comes if at all I convert all my workload needs or blueprints to hot templates tomorrow any other specification coming will there not be any challenges again for migration or movement of my workloads. So in that context I think one of the thing that is happening now is all the HEAT templates are becoming TOSCA compliant. So TOSCA I think there are different other providers who are also participating in this OSS-backed TOSCA compliant model where any template which is TOSCA compliant it is a XML based template that will be supported by HEAT. So HEAT can be the orchestration engine across different clouds where the workload can be provisioned across multiple providers. So in this way I think we should be able to consume the resources across multiple clouds. Now we actually got into the cloud platforms we consume the resources. Now the next question that comes to our mind is okay both of this is fine but after this how do I actually track my uses across different cloud platforms and how do I we talked about the templates but one of the basic need for templates is definitely if at all I do not have the same golden images available across the clouds how are you going to provision the resources across clouds. So to address these two needs it's actually a bit tough but I think there is a blueprint that's been proposed which is the tri-colors or cascading open stack. So I have just tried to reuse the same concept here. So if you see in cascading of open stack it's a very nice concept where what is happening is one parent open stack is exposed to the external world and all the APIs of that open stack is exposed to the external world and any other open stacks setups are actually called as cascaded open stack or it is similar to the concept of availability zones different availability zones across for a single service providers. So in this case first for uniform image management what has been proposed is at any point of time these are basically three different open stack setups out of this one works as the parent open stack and two others are the cascaded open stack right at any point of time if a image is getting uploaded to one of these providers then the replica manager there will be responsible for copying that image across other providers. Now this is something which is definitely debatable that do we really need to copy the images across open stack clouds or is there a any other mechanism. So for which the second option which is proposed in this blueprint is if we do not want to replicate the images for the first time when a call goes to any of the open stack where the image is not available for a resource consumption at that point of time the image gets copied to the target open stack. Now which means for the first time when we provision a VM with that specific image it might be possible that the provisioning time will be a bit more but if let's we are worried about the storage cost and others then definitely this might be another option and of course there will be other options but I think currently these are the two options that is proposed in this blueprint. Now second for usage tracking assuming silometer is the metering component so there is a proxy silometer so any point of time if there are any queries for any of the resources that has been provisioned from the other open stack platforms then what happens is basically everything comes from that silometer proxy which means that the data is getting usage data is getting stored in different platforms and when on demand the data gets aggregated and being sent to the user. So this is one of the way where we can actually have a consolidated metering or usage tracking but this is something which is there as a blueprint which has not come to the mainstream project yet. So now we talked about actually these were the three different concepts I wanted to discuss about in terms of identity federation, federation orchestration and the image management and usage tracking. Now we will actually talk about couple of marketplaces which are available today. So definitely when we talk about marketplaces the first marketplace that comes to mind and maybe we have seen is the AWS cloud marketplace. Now if we come to AWS cloud marketplace we can see there are different options available in terms of the software, in terms of various services, SaaS. So AWS marketplace I think was the first marketplace that was introduced with a similar model but having said that there is a question whether AWS marketplace can we really term it as a federated cloud marketplace because it is against the basic concept of heterogeneity of platform and combination of providers. So it is the single provider and it is a single platform. Having said that the marketplace model is definitely the one but definitely it doesn't give the complete federation where we said no it will be really good to have multiple providers coming under a single platform. Similarly another marketplace IBM cloud marketplace so at the outset it looks like no different applications as SaaS based marketplace which is available today and we can see no choose or pick applications or services based on platforms infrastructure type. So there are different choices that are available to the end user. Now the third I have taken is the compute next global cloud marketplace. So if you see here in the compute next global cloud marketplace it is currently you see all the IIS providers. There are almost 60 plus providers who are available under single platform in 28 different countries and 40 different cities. So the wide choices on the left hand side I mean if we see we can select the choices I mean the resources based on type OS country city or any kind of hardware and so there are different options available in this marketplace and this actually looks interesting. So I have another slide on that when I provision a workload in this marketplace how does it look like. So if you see it is again a workload based model so where on the left hand side I have selected resources in terms of compute and storage from different providers and on the right hand side whatever is been provided is actually by this marketplace operator compute next in terms of console manager which actually is nothing but remote console or a monitoring that can be enabled. So that is something which the marketplace operator itself is packaging along with various resources that is been provided by the providers offered by the providers. So this again is a good model seems to be the choice for different options for the end users. I think we talked about marketplaces and open stack cloud platforms right I mean but if you see right today whatever projects I talked about it is actually not only meant for open stacks alone. Let us say if open stack as a community right if we will only think about Federation of open stack clouds then that does not satisfy the basic definition of again the Federation. So because when someone wants to try open stack he should not have no any doubt in his mind that if open stack does not work I will invest lot of money and what is there will I be able to migrate or move my workload across to any other providers if there is a need. So that is why the projects itself be it the keystone be it the heat they are actually not only open stack specific if you see a keystone can act as identity provider to other cloud platforms as well. If you see the heat actually in our cloud lab in cloud enablers we have orchestrated the different resources using heat template to Amazon and other cloud providers as well. It is not limiting us to only try out certain things only for open stack right. So that is why the question or the thought I am proposing is we should not restrict the Federation though we started with Federation of open stack clouds it should not be limited to only Federation of open stack clouds actually it can go beyond that right. So then yeah so yeah these are a couple of references that is all I had actually any questions I will be any questions yeah yeah all right well so the question I had is networking in terms of you have got let us say you have got two different clouds that you are using for or two different clouds you are using for disaster recovery or high availability globalization is there a common standard we are developing with neutron because open stack is the Rosetta stone of talking different clouds to each other is there a standard with neutron to say connect this neutron network to that neutron network instead of having to right now it is just individual providers providing solutions but do we have people working on defining the standard to make those connections or to my local yeah that is a very good question if you will go to the cascading of open stack right I mean I talked about only kilometer and the glance but actually the same thing is done with the neutron itself where you know basically let's say you are provisioning two VMs across two clouds right and you want to apply the same subnet so that is possible but again that is something which people are have thought through but it's not implemented yet okay yeah I decided this wasn't sure if there was any any yeah so that is there as part of the cascading blueprint all right so any other questions so I'm sorry will you be could you please use the mic I mean that's a requirement from them otherwise it's not getting recorded thank you it is not clear to me in the slide whether he does the orchestration right who owns that heat heat more is the marketplace operator so it is the federation provider it is not owned by any specific cloud platform or service providers okay if no more questions thank you very much and