 So welcome everyone to this first session of the lunch. My name is Mario Spusta I'm working as a principal software development engineer out of a unit that is called developer experiences As part of Microsoft Corp I'm actually based in Europe based in Austria in Vienna You might realize that when I'm having some strange parts and pieces in my expressions But my manager sits in Redmond and we are part of the what we call global ISV team ISV stands for independence of the vendor. So we are working with independence of the vendors on integrating their technologies and platforms with our technologies and platforms and our main focus area guess what is Azure and cloud and Today I would like to talk about the efforts that we have done Together with Cloud Foundry from an open source perspective as well as on the commercial side with Pivotal with running Cloud Foundry on Azure and As well talk a little bit about some more complex architectures that we have implemented with some of our global ISV partners So I just curious who has used Azure before Who knows about okay, so that's maybe six seven eight nine tenish or so So who knows about Azure then? So quite a few people. Yeah, so Azure is Microsoft's public cloud platform for those of you who don't know it We have deployed it across more than 30 regions on the world a region is usually a metadata center that covers approximately 100 to 120,000 physical machines where we run workloads of all types reaching from Typical infrastructure as a service workloads up to higher level pass workloads such as machine learning Big data workloads with how to open things like that. So that's kind of the quick What is Azure in a nutshell and Cloud Foundry is one of the workloads that we are very proud of to Have on Azure. So with regards to that specific session I'm not giving an Azure basics talk or something like that I would like to dig into Aspects that we have experienced with the running Cloud Foundry on Azure. So these are the main key takeaways We'll talk about where we are right now. I'll show you how you can get a Cloud Foundry running on Azure using Bosch Then we'll talk about private cloud and hybrid cloud deployments. That is the middle piece of the section Well, you'll learn about our vision in terms of providing Azure in private cloud so in your own data center at the end of the day and also where we are with Cloud Foundry from from that regards and Finally, we'll talk about Globally distributed Architectures as we have experienced them with some of our global ISV partners The reason why I've that I've put that into the game is because those global deployments are usually multi-region deployments and you can look as a region as Either a deployment in one of our other public cloud vendors. Is it pivotal or AWS or whatsoever? Or it also could be your own private cloud and that is the reason why I put that into the mix of the presentation So Cloud Foundry on Azure where we are today So today we have released a CPI implementation for Bosch That helps you to spin up a Cloud Foundry cluster on Azure and it helps Bosch to do some or perform some automated management operations against a Cloud Foundry cluster that has been deployed that way That CPI implementation is all open source So we are actually developing it as part of the Cloud Foundry incubator project So we are doing pull requests into that their GitHub repository if you want so and that CPI is under Like active development in terms of it's getting improved on on a weekly and monthly basis So for example, we have heard about the ego this morning in the keynote We have that in our CPI implementation already for example So that is one part of the story the Bosch CPI obviously works against the Azure management APIs The Azure management APIs are just a set of REST based HTTP based services that do allow you to run management operations against your own Azure account or we name that Azure subscription and those management APIs Allow you to perform template based deployments with the technology that we call Azure resource manager templates So the second piece that we have built for running Cloud Foundry on Azure is guess what a set of ARM templates That allow you to spin up Cloud Foundry cluster easily on Azure so those templates essentially are spinning up the dev box and the Bosch Director instance and then from there you just dial into or SSH into the dev box and then Perform your actual Cloud Foundry cluster deployment using Bosch and the Bosch CPI that that we have Built so let's have a look at that So let's go to my other desktop. So what you see here is the Azure management portal. It's an HTML5 based portal I'm just running it in some sort of terminal management tool that I'm using for my own stuff So in reality, that's just a hosted browser. So don't get confused by that I just use that because I don't want to confuse my management stuff with Things that I'm looking up in the internet. So that's the only reason why I'm working like that So essentially one of the important things that you need to understand when you start with Azure nowadays is the concept of a resource group a resource group is a logical grouping of resources that do belong together and then on the resource group you can issue things like Like permissions for users Do role-based access controls And perform joint operations on all the resources that are in such a resource group So what I have here in that resource group or in the list of resource groups of our teams Azure subscription so that has a lot of resources. We are doing prototypes and PUCs with our Global ISV partners inside of that subscription. I have a bunch of them running here So CF simple here is a resource group where I have deployed a Cloud Foundry cluster In Azure and what you see here is a bunch of cluster nodes Those are essentially the workers where the actual applications are running And then you have things like Network interfaces public IP addresses and so on and so forth So that is essentially like a running Cloud Foundry cluster But the question is how do you get there right and the answer is to be found on a public GitHub repository Under Cloud Foundry incubator Bosch CPI release So that is where we have published all the ARM templates where also the Bosch CPI Implementation is available on as open source and that has a pretty Detailed guidance on on on how the deployment works and and what you need to do Actually So the first thing that you need of course is an Azure account or an Azure subscription So you need to have Azure and your own Azure tenant to be able to do that It explains how that works, but then it becomes a little bit more interesting Because then it talks already kind of very Azure style language you need to create a service principle So who could think about what a service principle is? So it's essentially an identity in a directory That you can give permissions to execute operations against your Azure subscription So essentially it's a service user that you need to add to your Subscriptions directory where you manage all the user accounts and everything that is backed by a service that is more in the platform as a service Kind of category from Azure, which is called Azure Active Directory So when you create a new Azure subscription what you get is an Azure Active Directory and the actual Azure subscription into which you deploy your infrastructure or platform services and in that directory since Bosch CPI in case of Azure acts as a service which Deploys virtual machines on behalf of us as the owners of the subscription It needs to have an identity for that and that is what you need to first create before you can start with that So there is actually a pretty detailed guidance here For how to do that, but essentially what you need is What you need is the Azure cross-platform CLI on your machine the Azure cross-platform CLI is a node.js based Command line interface which works on Linux Mac and Windows So I have whoops clear Clear Azure I have that installed here and then it has all sorts of commands like Azure AD SP create dash dash help So that essentially is the command that creates a service principle And then that service principle gets an ID and the secret for Signing in and this is something that you would need to fill in as a parameter into the template and Bosch uses that principle to create the VMs and delete the VMs Or do upgrades of VMs or whatever it takes to manage the Cloud Foundry cluster So after you have done that You actually can just clone that repository here In which we have the templates as they are developed and as they are released If you want to get more kind of like frequent updates, then you can look at let me open up a new Tap here Azure quick start Templates so there is another github repository where we publish like quick start templates which Kind of are more optimized templates for trying out things quickly So where you do need to do less Configuration at the end of the day so when you go with the plain templates from Bosch CPI You need to think about things like a IP address ranges and things like that that you need to configure in the template For for arm on the quick start templates. That's all pre-configured So you don't need to think about those things and just can try it out quickly. That's the idea and in there We have a Bosch setup Repository Where we have pre-built Azure resource manager templates and I have them actually open here in one of those Visual studio code instances Bosch setup So that is actually the right one. So this is an Azure arm template for deploying Bosch CPI and the Bosch director into Azure and then from there I show you how how you continue So this is the template essentially the template has a set of parameters where you can Specify things like VM name prefixes So like the main VMs like the death box and the Bosch director get that prefix your DNS name will get that prefix and things like that Those are things that are more customizable when you take the actual officially released ones from the cloud foundry incubator Then SSH keys for SSH into the death box and things like that And then you have a bunch of variables And then it starts with resources like network security groups that define the firewall rules for Azure and then things like Virtual virtual machines virtual networks So of course all that gets into a virtual network into which all VMs are deployed and so on and so forth and then Machines and finally the first virtual machine that you get is a death box essentially So this is the template for a virtual machine. It gets the default name Then in the top there is a variable where you can specify the VM sizes there You just specify the instance types which defines how many cores how many memory and so on and so forth you get And essentially what you do is you take that template You don't even need to look at that template What you actually need to look at is the second file the Azure deploy parameters file where you can fill in your stuff and This data here That is from the service principle that we created before the tenant ID is the ID of the Azure Active Directory the client ID is the ID of the service principle that we created and then the client secret is the password that you specified for that one And that is all documented in there and once you have filled out the template I have filled out one here under debug dot Azure deploy dot parameters dot JSON I'm not going to open that up because it discloses my subscription IDs and the secrets and some things You actually can pass them in through shell parameters as well if you prefer that but If you have that large number of parameters that becomes a little bit more of scripting effort essentially and what you do then is you essentially Go there and say Azure Group create Maria SAP CF summit Life, so that's the resource group. It gets a default location North Europe Enter and then you create a deployment based on that Based on that template with the appropriate parameters file. So Oh, thanks, let's Go to quite ours here. So and then you say Azure group deployment create and then you give it The resource group that we just created Maria SAP CF summit life template file Azure deploy Jason parameters file file and debug dot Azure Azure deploy the parameters and then it gets a deployment name CF summit deploy 0-1 enter and that starts the deployment of the Of the deaf box and the Bosch director actually for the Bosch director There is a parameter So it deploys multiple resources in parallel for the Bosch director There is a parameter in the template that says how to deploy Bosch that is disabled by default So from a learning experience that is what I would suggest to do from a production experience I would kind of automate the entire flow And then just go to bed and on the next day or morning. You'll have your CF cluster running I'll go for a coffee. So That runs then after you have that what you can do is SSH into the deaf box So this is what I have done here. So that is my deaf box CF simple. So that is just my existing Existing deployment and by default we have configured the arm templates in a way that they are working on Ubuntu LTS 14-04 so that is what we have here and when you when that deployment that I just started is complete that what you get essentially is a Directory with a deploy Bosch shell script So that is then if you selected auto deploy posh You don't need to execute that if you have disabled auto deploy posh What you need to do is like run that script So that is what I did here and that deploys your Bosch director using Bosch So that runs then for a while Since it's downloading stem cells and the likes from central CF repositories and puts them into Azure storage From where it can then deploy virtual machines After you have done that What you can do is deploy posh So for that there is a second script So let's go back to the active window, which is called deploy cloud foundry And then before you do that what you would need to do is look at Look at a Bosch YAML file Which would define the cluster setup for cloud foundry So what we do with the quick start samples is we like look at the Azure Arm template and the parameters that have been passed into that and we generate a Bosch YAML file that matches the parameters that you specified in the in the original arm template So and we have then two manifests that we generate for the quick start one Which works with a single worker CF node and the other one which works with multi worker CF node So multiple VM CF. That's a standard Bosch YAML file at the end of the day Where everything including the director URI and everything is like Pre-filled if you want so the IP address ranges those are those which have been defined in the arm template So when you take the native templates from the cloud foundry incubate the projects These are additional parameters that you would need to take care of And after you have that deploy Bosch running you have your CF cluster running in Azure And you can start managing it with the CF CLI And that runs then in a single Azure region So if there are questions, I would like to defer them to the end of the session since The time is fairly tight and we have still two more sections to go So next one Azure and cloud foundry in a private cloud So what you have seen now is Azure in the public cloud. That's across those 30 plus regions in Europe, for example, it's Amsterdam and Ireland where we have those mega data centers But what if you want to run that in your own data center with the same templates with the same management principles? And that is something where we made some some rather big announcements earlier this year and also yesterday at Microsoft Ignite Which is Azure Stack So when you look at cloud platforms in general that provide you Infrastructure as a service platform as a service and software as a service the high level architecture always looks kind of like that Very simplified, of course, right So you have some management tools and portals You have an application deployment model like Azure Resource Manager in case of Azure You have the foundation and you have a fabric controller which manages everything Now we have that in the public cloud and what we are doing with Azure Stack is Porting that back to enable you to run it in your own data centers But not just the infrastructure, but also the services that are running on top of that infrastructure So it's not that we just give you the like The the Azure environment that would kind of be similar Like open stack in your own data centers What we give you is Azure in your own data centers not with all services yet But our plan is to have as much parity as we can have so that we can give customers and partners as many options as as possible The management experience the scripting experience the management APIs are the same for both Azure Stack is currently in public preview Actually, it's preview to that we technical preview to that we currently have available and we are planning to launch it Around mid 2017 So now That said this is like high level view of pass and IAS services in Azure just to give you an expression This is the beginning of a journey So Azure Stack when it will ship will not have all the pass and IAS services available Just those where we get most Feedback from our customer base that we should prioritize those services at the end of the day Virtual machines virtual networking and and all that stuff that is needed for Cloud Foundry will be there So What does it mean for Cloud Foundry on Azure? So essentially what we have seen are those ARM templates So the these templates do deploy Bosch and the Bosch director in Azure public cloud What we are currently working on since Azure Stack has a bunch of limitations with regards to those API APIs ARM APIs and With that also the template functions that it supports today We are back porting the ARM templates that we have for Cloud Foundry available today as part of the Cloud Foundry incubator Make sure that we only use the API surface that is available in Azure Stack and then we'll as soon as we have That done we'll publish it on our github Repository with the quick start samples as well as the Cloud Foundry incubator as well And then deploying Cloud Foundry on a private cloud Azure Stack environment would be exactly the same What I just explained because the Bosch CPI that goes against ARM API's which are pretty common for both platforms So we don't have a lot to do there But on the template side of the house we used a lot of convenient functions that make it easier to offer the templates Which are not yet there on the Azure Stack So there are some examples on the deck of that as soon as that is available You'll find it on our public github repositories and that is kind of our private cloud Story when it comes to Cloud Foundry, but I would like to expand that story by looking at two real-world deployments that we have implemented with partners Which are a cross-cloud cross-region deployments and then put that back into the context of hybrid as well because Hybrid deployments and private cloud does not necessarily mean that you have Azure running in your data center And we know that and we want to enable all sorts of hybrid scenarios Not just the one where you have Azure Stack running in your own data center Actually, we assume that it will take a while till we have customers running Azure Stack So the reality will be that most of them won't have Azure Stack anyways in their data center So we are looking at Those scenarios actually even more as we talk as we are talking about today So and I think globally distributed environments are a very good example of that because they put you from an Architectural point to an edge that will for sure enable you to implement the same thing with the public private cloud setup Because that's gonna be a little bit more easy or easier at the end of the day And that is the reason why I added that section. So now when you run Globally distributed Environments and in our case we were working with three global ISV partners over the course of the past eight months to implement Different types of distributed cloud foundry deployments on Azure All three of them were pretty large enterprises and When you look at a distributed cluster, there are different ways how you can achieve things and Depending on what requirements you have especially in terms of a recovery point objectives and recovery time objectives You might want to take Certain compromises or not, but then live with an increased level of complexity So that is always the conversation that I would suggest anyone should have before you jump into something like What I'm presenting here right now because if I would stand here and say our things are getting easier with that I would be wrong, right? I mean, we know this will increase complexity So essentially the options that I have seen are two main options One is a little bit easier. The other one is a little bit more complex The first one that I've came across is like running two separate Individual cloud foundry clusters across two Azure regions or an Azure region and another cloud provider There that is easy because you manage those CF environments pretty individual from each other You don't need to really connect the networks or not for the sake of the cloud foundry cluster at least And from that perspective, that's easy to do that works well for cloud native applications Which are stateless which are outsourcing state to some third-party services but if you run everything inside the cluster then that deployment topology might not be appropriate or Fulfill your requirements. So the other option is the hot one which is running a single CF cluster across two regions And we are going to look at both of them from the Azure perspective So here I have put together a little sketch of what we have worked have been working with one of those global ISVs That's the separate CF cluster deployment Essentially in green you see an Azure region inside of the Azure region in the customer subscription We deploy the Vnet so the Vnet essentially groups all the machines inside of the region together So that is one part of the story then there is the other region And in the other region you again have the cloud foundry cluster running individual on its own So for the cluster what we have here is we have different groups of virtual machines Which we group together in what we call Azure availability set and availability set in Azure is a concept That allows you to group machines together Which must not fail or be down at the same time Like because of a failure or an update or whatsoever with that the Azure try The Azure fabric controller makes sure that those Machines are deployed across different fault domains in Azure a fault domain is Depending on how the data center is deployed if it's a rack deployed data center The fault domain is a rack because the rack has a top of rack router Which connects all machines of the rack to the rest of the data center? That's a little bit simplified, but essentially that's That explains the concept. So if you put VMs in an availability set in Azure The fabric controller makes sure that the machines do not get deployed on the virtual machines to not get deployed on the same rack so we have that here for Reverse proxy which that customer needed for certain authentication scenarios. So essentially they pulled Authentication out of cloud foundry into their own infrastructure and then we have an availability set for the cloud foundry cluster Resources and finally for some other external storage resources like my sequel Now what they did then is they had a cross region connectivity But not for the sake of cloud foundry, but more for the sake of syncing the my sequel cluster underneath and The gamefire cluster underneath which did run outside of cloud foundry in in this case So and then the final thing that you need to do is put a global traffic manager on top So that's the Azure traffic manager, which is a DNS based routing Routing Which can route traffic to one or the other region based on low balancing probes health checks and the likes So that is one kind of deployment that would go pretty much of what we have seen before like you deploy the Individual clusters like we have done it before and then you're pretty much done And then you set up the cross region vNet the other one is exactly the same Except that we again had to run certain resources outside of cloud foundry and I'm getting back to that But we had one single cloud foundry cluster running across regions And in that case what you see in red are the resources that are used by cloud foundry themselves to itself to manage its configuration For example cloud foundry has the concept of a configuration database called CCDB or a user accounts database called UAADB And those are by default if you take the default YAML file They are stored as part of nodes inside of the cloud foundry cluster If you want to operate a single cluster across region That doesn't work because cloud foundry does not give you a lot of control in terms of how to structure those Databases in terms of how they run inside of the cluster But for a cross-region deployment you need that control because you want to replicate them depending on the RPO and RTO that you need To fulfill so we had to pull them out Run them as cross-reaching clusters in separate virtual machines or use third-party past services like clearDB Which is my SQL as a service on Azure and Outsource the configuration to those To those services rather than running them inside of the CF cluster The other thing that we had to do is like modify the the Bosch YAML file for the cloud foundry cluster to make sure to have Different cluster resources for the different zones. So let me show you what I mean by that So that that is actually the the next demo already. So I'm picking that upfront so now when I Look at visual studio code here On the left-hand side, I have a YAML file for a cross-region cloud foundry cluster on the right-hand side I have the ordinary cluster. So let's search for CCDB So in that case that is the configuration that how it looks like when CCDB runs inside of the cloud foundry cluster So there must be So DB scheme so it's using Postgres and it's running directly inside of the cluster. So here CCDB Here what we see is an external IP address or an IP address in a cross-region vNet That has the external mySQL cluster running So that is the easy part the trickier part is the NFS server that cloud foundry uses for the storage Aspects because here on the right-hand side It just deploys an NFS server inside of the cluster whereas on the left-hand side We had to specify an external NFS cluster with its IP address now That's easy, right, but you have to run NFS cross-region So that is where you need to do things like running NFS nodes in one side and on the other connecting them with DRPD and things like that and Currently I have all of that work in progress on my Github repository MSZ cool Azure quick start templates, but not this one so where Bosch CF cross cross Bosch CF cross region where I Actually have scripts for the foundation that are automatically deploying Things like a Maria DB Galera cluster across two regions So that is here the jumpbox install Maria DB cluster and everything So you can have a look at that probably you are more experienced in bash than I am But this is what we are currently working on and open sourcing as well to enable These kind of deployments right so that is one part of course But the other part of such an architecture is one side could sit in another cloud provider And when you think of the really large enterprises, they most often want to follow a multi-cloud Vendor strategy, so they would like to have for example one thing running in Azure and the other one running in their own data center or an AWS and Unfortunately time is a little bit tight So I won't be able to show that anymore But I can actually and I will blog about it so you can read read about it after the The conference or my blog is blog msz cool.com. You'll find it there today or tomorrow. Let's say tomorrow What I have configured here in my Azure subscription is a So when you look at this here, so The deployment is one part the DNS based routing is another one. So what I have configured here in my subscription Under CF region foundations is a traffic manager Just to showcase the hybrid aspect a traffic manager policy that indeed includes Both when I look at the end points a pivotal based deployment which runs in Pivotals own cloud Versus an Azure based deployment which runs In Azure in the CF cluster that I I've actually deployed and that one gives me a single end point For both of those deployments. Yeah, I don't want to submit anything. So let's copy that. That's the app on Azure What I plan to do in the session is like stop the app on Azure and then after two or three minutes We would fall back to pivotal and that is a very good example where you have cross cloud provider high availability with actually Two different cloud foundry clusters running between Azure and the different cloud. I promise you I'll have that block out before September 30th and then you can read about it and With that actually I think I I should stop now, right? I'm talking too much. Thank you so much. I hope that was interesting