 Welcome to, I'm Mr. Murky, I work for Bosch. So, I'm Jatin, I'm an engineer, I work as a private law in London. I work as a software engineer. I currently have to solve the problem of back-to-back language during the platform. But today I'm here to talk about something else. I'm here to talk about the problem of deploying a software across multiple cloud providers. Or do I mean by that, so deploying or making a deployment in which one component is on a cloud provider like AWS and another component is on another cloud provider like vSphere. More specifically, I'm going to talk about how you could do that with the sidebar that I was looking on, which is the Bosch Met CPI. So, this is, this plots into the CPI interface for Bosch to essentially enable you to do multi-cloud deployment. So, the goal of this talk is to highlight the possibilities of multi-cloud deployment and how it could be achieved using this project development and Bosch. So, yeah, so this talk is divided into four unequal parts. We are going to look at Bosch for a while and look at, see how the CPI interface works. After that, we are going to talk, like I'm going to introduce another CPI project and how that works. We'll look at some new spaces which might include some demos of deployments across multiple cloud providers. And after that, we'll discuss some variables. So, yeah, Bosch, I guess it's very familiar to this crowd. It defines itself like this. It's a deployment of this creation and release management tool. It also does infrastructure provisioning for you. It's like the most common way of deploying Cloud Foundry. So, it's very popular in the Cloud Foundry community for that reason. We have to use Bosch quite extensively. So, we use it to manage tools like Conforsion. And we also use it, like especially the things that I work with, to manage data services with Cloud Foundry. So, for this talk, we are specifically interested in the release management, sorry, the deployment aspect of Bosch and how it creates instances. So, let's see how does the interface, how does the Bosch interface look like for an operator? So, imagine that you are an operator trying to like deploy software and this is the olden days and Cloud Foundry does not exist. No CF push. Like you have just received some software from your computer developers and your support provision. So, how do you interact with Bosch director to do this environment? So, the first thing that you do with Bosch is upload something called a stem cell. A stem cell is a bare bones operating system image which contains just the operating system that needs to run on that particular IS. It also has some IS specific metadata. So, a stem cell on AWS is an EMI. A stem cell on vSphere is an ISO, I don't know if it is on vSphere. So, something which is IS specific, which is essentially a disk image that can start up an instance, right? So, the second thing that you do with Bosch is you upload a release. A release is your software packaged in a certain way. So, as you might know, there are called Foundry releases that go on Bosch. So, like the code that your developers have given you, you can convert them into releases and give them to Bosch. So, Bosch knows how to restart your software, the software dies and it knows how to check if the software is alive. What you do after that is you essentially go on your infrastructure provider and create some resources. So, if you are talking about AWS recently, you probably go and create some subnets and some, like you typically create a virtual cloud on AWS and these resources you create independent of Bosch. And then you compose what is called as a Bosch Manifest. So, this Manifest tells Bosch what the deployment should look like. So, in our case, say that you want to deploy an Nginx server, an SQL and like doing servers for your app to run. And you also put in references for the resources that we have created on the IS into this Manifest. So, Bosch knows where to put these things that you will create. And when you give this deployment Manifest to the Bosch vector, it will make it so. So, it will essentially converge your infrastructure to that deployment Manifest. So, whatever the machines are missing, it will create them if there is a machine that is running and it is not present in the deployment Manifest anymore to delete it. So, it allows you to create a Manifest, which is an exact, like which defines what your machines are in your deployment. So, you could do this workflow. The workflow that we just discussed, how it starts with this and Manifest with the first app. You can do this today on AWS, VMware, OpenStack and Azure. And your workflow as an operator remains the same to you on all of these providers. So, the reason for that is, Bosch defines a cloud provider interface, an interface through which cloud providers can have Bosch interact with it. So, this is what the interface is essentially. This is the interface. So, these are 18 odd methods that are defined that translate Bosch-specific calls into IA-specific calls. Implementation-wise, this is implemented as a command line binary. And this is put on the same box or the same machine on which Bosch is running. So, these methods essentially create resources on your cloud and give back an interface to Bosch to track those resources. You mentioned that you have to set up your VPC and your subnet and so on by hand manually beforehand. Why does Manifest allow you to specify those resources as well? Is there a reason for that? So, I'm describing the current state of the world. So, I don't know the historical reason why exactly it is like that. So, you could have, if you enhance the interface to even have three VPCs could probably do that. But probably there is no unified interface across IA-provided. That's why there is none. I don't know this answer. So, the CPI has like 18-odd methods that I was saying. And it returns clouded files for Bosch to track the resources that it creates. So, let's look at the flow on how the Bosch director interacts with your cloud on AWS. So, if you just go through the operator flow again, so the first thing that you do is clear yourself. So, when you say create steps to the AWS CPI, which is a CPI parameter on the CPI parameter, this AWS CPI is now responsible for translating this create steps of code into an equivalent code on AWS. So, the AWS CPI does the raw things and the last color it invokes is the create volume code. The create volume API code on AWS which will create essentially an AMI. So, the AWS then returns an AMI ID which it then passes on to Bosch. And so, whenever Bosch wants to create a new resource with that AMI code to create a new instance, it is essentially referred to that image using that clouded identifier it got from AWS API last time. For example, now you want to actually create a VM. So, use the create VM CPI parameter. Bosch uses the create VM CPI parameter which then gets translated into a AWS specific API which happens to be run instance with that AMI ID. So, it will essentially start an instance on that image. So, as you can imagine, then the AWS API then returns identifier which tracks that instance after it has started it. So, whenever the Bosch vector wants to say tap that instance or kill that instance, it will use that identifier. So, currently only one of these cloud providers can be specified with Bosch. The way that people do multi-cloud deployments today for stuff like Cloud Foundry, essentially they have two separate Bosch directors on each of the hi-hazes. So, you have an AWS IR and as your hi-hazes and you have two separate directors and you compose two separate mark-hazes. And then you manually converge from by yourself like so you push to this director and then push to that director. And so, what if you wanted only one Bosch director to manage multiple cloud providers? Well, this is the right talk. Introducing the Veta CPI. So, Veta CPI is a concept project that I was working on on the site. So, this allows you to deploy multiple cloud provider interfaces on the same director. And then the Veta CPI essentially acts as a router between those cloud provider interfaces so that it can translate the CPI caused by a piece of multiple cloud providers. So, it does this by two main things. So, it does this by inspecting the stem cell metadata to figure out which cloud provider the stem cell is for. And it works by tracking the cloud area it gets from the CPI so it can route back to the right place. So, let's take an example of that. So, this is our setup now. So, before there was just a Bosch director and the CPI and the CPI server. So, now it's as void output. There is a Bosch director with this Veta CPI, like multiple CPIs that you want. So, you have AWS CPI and Azure CPI which then interact with the cloud. So, when there is a Veta CPI, Veta CPI inspect the stem cell and understand that that stem cell is for the AWS CPI, for example, because as we mentioned about stem cells are CPI specifics. They are created for a particular cloud provider. After that, the AWS CPI will return it as we saw before a cloud identifier for that image which will, this Veta CPI will now record that cloud identifier and know that it had come from AWS and then forward that request again. So, for example, we upload a different stem cell. So, this time it's here, Azure stem cell. So, this request is forwarded to Azure. Azure returns it a cloud identifier for that stem cell and that stem cell, that is now recorded in the store of the Veta CPI say that that stem cell is from Azure. So, now subsequently, when we get a Veta stem cell request for like, or Bosch will refer to a particular cloud provider, the cloud ID that it bought, Veta CPI will know that it's for the particular cloud from looking at its storage and it will make that request on a particular, on the cloud provider that it got that resource from. So, this happens to be AWS. Then the AWS CPI will, as we saw before, will give it instance ID which it will track again. So, it will keep a track of the instance ID and all subsequent actions that happen on that instance. For example, if there is a tag instance action that happens on that instance, the Veta CPI will know by its lookup table that it should forward that request to the AWS CPI. So, this is kind of how it works. So, the next section is a bit more intense. So, how do you actually configure this in your manifest today? So, this is how a Bosch director's manifest really reacted looks like today. So, as you can imagine, what do you deploy the Bosch director by? So, you have the Bosch release and today you put in, co-locate the AWS CPI release and then you tell the director that the CPI that you want to use to provision machines is the AWS CPI. So, this is how it looks like today. In the Veta CPI case, you will essentially deploy the Bosch director, deploy the other CPI that you want and deploy the Veta CPI. So, this is the director that you would actually like to point to the Veta CPI. And in the Veta CPI properties, you can tell the Veta CPI about all the available CPIs on that machine. So, you could get the funds of different cloud provider places that exist that you have deployed on the same machine. So, how does a job definition look like? So, this is a job definition in your deployment that you are trying to make. So, we have already looked at how the yamen looks like for what the directorates are. So, how can you configure the deployments that you are going to do on the meta director? So, as everything over here is based on stem cells, as normally you would define a particular stem cell that you want to deploy to, now you define multiple stem cells and when you define a job, you stem cell determines which infrastructure it will be deployed to. So, you also give it a VM type and a network type. So, right now there is no validation to check that the network that you are deploying to actually belongs to that particular IS, it could just straight away deploy and the underlying IS will throw in error because it does not know that network. So, to help with essentially creating VM types that are applicable across the cloud, across cloud providers, the MetaCPA also supports like what I call meta cloud definitions. So, this is what a typical cloud efficient looks like today. So, there is a VM type which is called a small VM and in the cloud properties, you give an instance type of T2 micro. So, this is how it looks like today in bot. So, you tell a small is essentially a T2 micro and it will be deployed on that availability zone. On the MetaCPA, what you could do is like the VM type is small and in the cloud properties there is now a meta block in which you specify on Azure a small looks like a standard A2 and on AWS a small looks like a T2 micro. So, similarly for networks, this is how a typical AWS network will look like in your cloud conflict today. So, you will have your defined AWS network and say that this is a particular subnet that you are targeting, like that is the subnet that this network refers to and those are the IP rings similar to VM types and the MetaCPA also allows like meta blocks for VM networks. So, you can say that in Azure like the network or compilation on Azure should go to Azure VM and on AWS should go to subnet ID AFV, whatever that is. So, this is how you can define like define network types and VM types that are applicable across multiple cloud providers. Alright, so that's the end of the video. Good to be on most of the video. Alright, to conclude, the MetaCPA is a project which essentially acts as a router between multiple cloud providers. It can deploy them in parallel on a machine and then act essentially as a switch between those. It also tracks the cloud IDs that come out from those CPIs so that it can route the subsequent requests correctly back to the same cloud provider and it provides special configuration blocks so that you can configure VM types which are applicable across cloud providers. Now, the use cases. So, the most obvious use cases of course is doing multi-cloud deployment which means that before you had a voice director on both the sites or both the ISs now you can have a deployment in which you have only one voice director just sitting on either side. You connect those two VPNs by a tongue of some sort. You have an AWS instance and Azure instance and you load balancer by external load balancer. This VPN is not part of your actual network. So, just like you do network scanning you have to use the VPN terminal. So, for this demo it's really simple. So, what I have deployed is what's my location release. So, it is a simple release which just fits out the location of where that is being run. I have two stem cells as I described. The release is the current location release and if you go down, I have defined two steps. In the network definitions for the job you can see that I have assigned the Azure job a static IP in Azure and like in the normal Azure network and so this is on the Azure side with the Azure stem cell and with only one VM definition. On the AWS side it uses the AWS network and has a static IP on the AWS side. If you look at the cloud config for this the AWS network is an old style network you can see which is just tracking one subnet so one of those machines will be deployed to that subnet and the Azure network is also like the old style wash network definition which is tracking a subnet or subnet one on Azure. The VM type is actually using some new meta structure so there is just one VM definition with specifications written for AWS and Azure. She did not have a load balancer at hand so I'm just creating a hacky load balancer with Nginx and essentially putting both those IPs in Nginx so that it will load balancer over it. So right now we can see the settings in my AWS account in my AWS account I have my director hanging out there and I have a gateway essentially so that machine over the AWS to Azure gateway is forwarding all the traffic in that subnet to the Azure network. On the Azure network I've used one of the templates that are available online to essentially to a site-to-site connection so I have a VPC gateway which is receiving traffic and sending traffic back from the subnet in Azure to the other side my local host is not loading because the deployment is not done yet so if I go to my terminal and do a botched deployment and if we refresh our AWS console what we see is an AWS machine is coming up on the AWS side so this is our machine that is starting up and on Azure if you refresh you also see an Azure machine being created on the Azure side by a single botched deployment. For a minute it will all be done and if I hit my load balancer I would have traffic essentially bounced across the cloud providers so you have the AWS cloud provider with that IP and Dublin which is... the first one is actually Azure and Dublin so the other thing that you could do is run errands in current container so currently when you run errands which are one of the four tasks what should essentially start an instance for you and run that food in that instance and delete that instance later the things that we typically do in errands are really small which is like registering a local cloud foundry so that they can essentially run in garden containers garden is the container runtime for cloud foundry which there is a CPI written on top of it so we can deploy the garden CPI the garden software and the AWS CPI and have a deployment in which some components can run in containers and some components can run on the individual machines so I'll demo that so this is just demoing errands so this is everything is startup eight times so we have two Bosch errands one is just saying hello on AWS the other is saying hello on Warden so when you run the AWS errand you will be spinning up an instance for you to do the task and it will come to you sometime so all of these are mistakes and the actual work that was done essentially done in that one second which was saying hello as you can see it completed in three minutes and the second errand is just being done on Warden you must have so that was done in 26 seconds so you just spin up a container run the software it wants to run and spin down the container so containers are really useful for startup so the other use case is essentially the one that interest me the most is cloud hosting in which you have a user deployment like you have a watch deployment on your vSphere environment vSphere as it's on your premise you cannot expand it like a cloud if you want to boost you have some seasonal capacity overheads in which you want more capacity just for that season you could use a public cloud like Azure you can run on your vSphere deployment to Azure and run specific the additional capacity beyond smudging there is no demo for that yet the other one that interest me is how can you how can you use specialized hardware on specific devices so AWS has this really same machines which are like 8x large which are really nice for like mining bit points and which you could spin up just like for your one-off use cases rather than just go on AWS to use one specific instance you could run a normal cluster of your own on your premise and just go to AWS for things that you need so there we are so of course like the room for this kind of things is network latency between AWS and Azure so when I measured it was around 8x slower to send traffic between AWS instances and send between AWS and Azure industries so that's why application awareness is very important for example if you deploy Cloud Foundry on such set up today like if you have to have this on AWS and Azure and the able nodes distributed across them it will actually forward traffic down into one AWS provider through the through the virtual through the tunnel to the other side to handle 50% of the request because the outputs don't know which nodes are closest to them that's why application awareness is really important in this kind of scenario it's fine for doing one time deployment so if you do a deployment and then it can turn on its own on the other cloud provider it's all good so if you need to communicate on the request basis this is bad so application should be smart enough to work in these scenarios security is just based on whether VPCs are kind of a sort problem it just provides one more moving component in your infrastructure so now you have to take care of your tunnel key which is one of the most important components for you now and of course there are some caveats like meta-CPI, meta-CPI is still also for support is easier like the meta-easy are not supported meta-prisks are not supported compilation must be done and I'm in that course that's all I have to say about that can you share sorry I might have missed a bit where you had me where you said I used to do my errands on the garden and that's awesome so what was the manifest look like? I looked at your repo and it shows how to deploy a Bosch with all the CPIs because we've been deploying Bosch lights with Bosch and it never occurred to me that hey why don't you also have another CPI that can do some real work but then you can run the little jobs locally so I have to find the port right now and open it so can we take this offline it wouldn't be much easier can you put it in the way part yeah sure so I will I will add that manifest to the repo as well yeah so the repo lives lives here if you have interest in this approach to contribute and I'm open to taking in contributions for that if you do any deployments with this CPI like and if you want to put your sample manifest here I'm also open to that including mines I know can you give me a gist of it, why don't you put it in an area and decide which CPI you just say the stem cell you say the stem cell network so you create but you just do it on stem cell okay is there any way to automate the placement of your workloads based on monitoring or resource usage or any other kind of contracts of the CPI I feel that is not in the scope of this particular product so this is really to distribute requests between the VM creation requests between your cloud providers that is really at the higher level like in which you understand what the application is doing and you want more resources of this application on the per side yeah so you have to find out what is the future of this work is it a product or is it a product or is it just a product this is not a product so this is open source you can use it is it a product or something no not yet it will probably be part of the project yes is that trace to deploy to multiple of the stem cells I have had a question before especially on AWS as well I don't know how to do that how could you deploy to multiple of the stack instances with this we can if we want to file it we can just cut the stem cells we can do it it affects the metadata the stem cell metadata the stem cell is nothing but a strategy set you can open it in your whatever it won't be the one that is published by the Bosch team so it's not ideal so you can hack along with it we can add like a we just want to start building anything even if you find a stem cell we can add another little piece of data back to the merits you have to pick up to help guide any other questions yes how is state managed is the AI tracking yeah so the state right now is it just goes and has to JSON file this ideally should go in the database so share the database that Bosch uses you are not intending to how do you do version management like how can I get stuff if I want to have two stem cells or support two versions of two stem cells right now how is that to solve that in the future so that is still possible right so we can just do that workflow as it is in Bosch a way to manage stem cell versions that won't change with this we will just know that this particular stem cell is for that provider