 Good afternoon, everyone. Thank you for coming to our session today. I hope no one had trouble finding the spot. Thank you, though. Thank you for coming. My name is Kundana Palagiri. I'm a program manager in the Azure Compute Team. I work on primarily infrastructure service. And with me here is Ning, my colleague. Yeah. My name is Ning Kwong. I'm the program manager for Azure Open Source Technology Center in Shanghai. And our team work on open source technology on Azure, and also the Cloud Foundry engineering work. Cool. So let's get started. Today, me and Ning, we are going to talk about Cloud Foundry in Azure. And what we want you to take away is learn about Cloud Foundry's support for Azure and how you can manage your workloads, whether it is in Azure or a hybrid cloud environment. So before we take a look at what we are supporting, this is a high level picture of what we are going to be enabling with this announcement. So we are Azure is providing a Bosch CPI implemented using the new resource manager APIs. And I'll get into the details of what resource manager APIs are in a bit. So we have the CPI for Azure. We are also going to leverage the Azure templates for simplifying the deployment steps. Again, in a bit, we'll get into what Azure templates are. Basically, we'll show you how Azure templates can simplify deployment. And we have actually embraced the community model for supporting the CPI. And the last but not least is we have provided consistent user experience for multiple clouds. So what that means is the experience that you get for deploying Cloud Foundry in any cloud platform is consistent with the experience that you're going to get in Azure. And finally, using Cloud Foundry in Azure, you can also extend your on-prem workloads to cloud. We'll again get into details of what all this means is. What are engineering goals? So when we started on this project, last December, we took over the project of enabling Cloud Foundry CPI. There was already some work in a GitHub branch. So when we took that project, these were the engineering goals that we had in mind. First and foremost, we wanted to ship an all-open source project under the Apache 2 license. This project is today available in that URL. The next thing is we wanted to be part of the community. As we develop the CPI, we wanted to actually leverage the power of the community and contribute to the community. And also align with the community's engineering practices, whether it's the testing practices, the unit tests, CI setup, et cetera. And the next thing, the goal that we had was, as we take the CPI and adopt it to Azure, how do we simplify the deployment steps in Azure, whether it's by providing some kind of pre-created templates or by providing documentation? And finally, we have taken a crawl-walk run approach. This is our first step to support Cloud Foundry in Azure. And we have an ongoing commitment to enhance this support in Azure. So before we get started, I want a quick show of hands. How many of you use Azure? So why Azure? Why did we do? Why did we actually start this project of supporting Cloud Foundry in Azure? One of the reasons is our customers have asked that they want to run an Azure. And that's simply the reason why we've taken on this project. But a bigger question, why Azure? Azure is Microsoft's cloud platform environment. And as an open cloud, it supports hyperscale enterprise-grade and hybrid environments. So Azure supports both platform as a service and infrastructure as a service for both Windows and Linux environments. Little bit, we'll get into details of what this means and why this is important. So first thing is the hyperscale part. So hyperscale is the ability to run your code anywhere you want, knowing that you can scale up or scale down without worrying about capacity, running out of capacity. So Azure, as a hyperscale cloud, is actually operating in 19 data center regions. What this gives is, again, unprecedented access to capacity. This is an investment we've been, it's an ongoing investment from Azure for the last couple of years. And then this slide is a point-in-time snapshot of the technologies that are supported in Azure today. Azure is a path to actually embrace many of these open-source technologies. This does not actually reflect everything that we support today, but are some of the technologies. So if you look at tools to provision resources in Azure or the languages that can be done in Azure, this is a growing list. You can do it not only from our own tools that we provide, but you can also do it from some of the third-party tools that either we have worked with them to integrate it to Azure or provided by the community itself. So the next thing I want to talk about is the Azure Resource Manager, as one of the building blocks that we use for managing infrastructure in Azure. So before we talk about this, I want to give a quick background of why this is important. Previously, when you create resources in Azure, whether it is storage, network, or compute, you would have to provision all of them separately and then connect them. And then you need to connect them together. What Azure Resource Manager brings to the table is it actually gives you the power to define declaratively the resources that you are going to use in your application. You can set the dependencies between them. And once you have defined your infrastructure in a JSON language, Azure Resource Manager is responsible for instantiating all the resources that were specified in the Resource Manager. And it does that by using an orchestration model. And it also supports rollback. And behind the scenes, when you define your infrastructure in this JSON template, this is a JSON file which can be checked into a source repo. And it also supports things like parameterization. So you can define various environments, your dev test stage, and you can provide different parameters for each environment. So why this is important is to do repeatable work. These templates can be a real time saver because huge time saver because you are defining everything in a template and reusing. So just an example of how we have taken this template model and we have applied to Cloud Foundry. So here's an example. So if you have used Cloud Foundry, the first step you know that to set up your Bosch virtual machine, you need to go through certain prerequisites, like create a storage environment, virtual network, reserve some IPs. If you don't have an existing dev box, you need to set up one as well. So we have taken all these steps. And we have provided a Getting Started template. This template, which is available in GitHub, I can share the URL after the end, this template behind the scenes, it provisions all these resources that we have talked about here. And it parameterizes all of them. So you can specify your own parameters for creating this. And when this single click template is deployed, you get this environment configured for running Bosch. So again, as you use Azure for deploying Cloud Foundry or other resources, you will come across the templates in many places. And Ning will demo the template. So the next thing I want to talk about briefly is the hybrid Cloud environments. How does Azure fit into the hybrid environment model? So many of our customers that we work with have a model where they have some resources on-prem, whether it is an Azure-based Cloud or whether it's their own private data center. And they want to extend it to Azure. So with the work that we have done with the Azure Resource Manager and Azure Stack, you can actually take the same CPI and make it work both not only in Azure but in on-prem as well. So this is where Azure Stack comes into picture. So Azure Stack is the Azure APIs for private Clouds. Azure Stack, which was announced recently last week, a couple of weeks ago at Build and Ignite, basically takes existing Azure APIs and makes it available in private Cloud, like I said. And it has a consistent architecture. So it basically enables the same hybrid enterprise-grade hyperscale model. So what that means is, if you have an application that is running on-premise in an Azure Stack environment and it's running in Azure, you can use the same CPI. Our vision, at least, is to use the same CPI and target a different endpoint to manage that application in Azure Stack. And what this gives us is, this really enables the same ecosystem, the ecosystem that is available for Azure customers today is also would be available for the on-prem data centered customers as well. OK, so Ning is going to give an overview of Cloud Foundry deployment in Azure. Thank you, Kandena. So for Cloud Foundry on Azure, this project is all standard for any cloud providers. If you want to onboard Cloud Foundry on this provider, usually you need to provide the Bosch release, the storm cell, and the manifest file. And for us, we deliver exactly with the same process. So for the Bosch release, the main engineering work is the CPI, which is the cloud provider interface to Azure, enable Bush to talk into Azure through this interface. That's the major work. And then the Coresp content Bush component that needs to be updated in align with the changes for the new CPI. So that's the main deliverables. And we also build the Azure storm cell currently for, it's already in beta release. It's originally, currently, it's in Ubuntu. And pretty soon, we will support CentOS and Red Hat. So these are the two main engineering deliverables plus the manifest file. And the next one is the resources management template, as Kandana just mentioned. This is the pre-configured template that simplifies your setting up, the setup of the Azure environment. And then just align with most of the cloud providers, we will also provide the end-to-end guidance about how to set up and deploy Azure, Cloud Foundry on Azure. So this includes the support for both the single node and the multiple node Cloud Foundry VMs. And also, we will have guidance for both the standard manual steps as well as the guidance for how to use the predefined template to configure the environment. After that, one thing we're also planning is the Cloud Foundry cluster setup. So we know after we enable this infrastructure on Azure, the next step is an admin need to create the Cloud Foundry cluster. So that will include database setup, low balancer networking settings. And we will work with the community to optimize these resources and work with community to provide additional guidance and the setup documents. So that's the major deliverable. So one of the things I want to call out is even though right now the project is ready, we finished it, but we really didn't release it until we wanted all the documentation to be updated. So this is an important deliverable as well, like providing this documentation along with the CPI. So the Azure Cloud Foundry deployment experience is quite similar than other existing Cloud providers. Usually, it contains two parts. The first one is the Azure environment setup. This is the every provider need to have. The second one is deploy the Cloud Foundry. For the environment setup, the first thing you need is the account. You need a subscription to hold the enough Cloud services and VMs for your Cloud Foundry VM network and the storage account to hold the VHDs. Network environment is the major part. Usually, this includes the VNet and the two subnets and also the public IP for BUSH and Cloud Foundry. Next one is for the secure communication between BUSH and the Cloud providers. Usually, you need a certificate, key pair. In Azure's case, we have service principle for your subscription, and we have detail step for that. For all these, we have end-to-end documentation, and we also have a single click deployment with a template. The other part is the deployment of Azure, the deployment of Cloud Foundry. This is almost exactly the same step as any other Cloud providers. So usually, this includes create a depth machine, which you will load the stem cell and the BUSH releases. And this depth machine can be any machine. But for our beta to simplify your experience, we actually created for you in our template. And then the next step is configure and deploy microBUSH through that depth machine. And then you can also configure and deploy BUSH or even multiple BUSH from microBUSH. We know most customers can be accomplished through the microBUSH, but some customers they have a more complicated infrastructure. They want BUSH or multiple BUSH that's also supported. And then you use BUSH or microBUSH to create the Cloud Foundry network from here. And these are the steps that consistent with all other Cloud providers. So if you are already familiar with any of these, and this is a very simple experience for you. So can I ask a quick question? How many of you use multiple BUSH environments to deploy Cloud Foundry? Otherwise, is it single BUSH environment? Most cases? Thank you. So Cloud Foundry template, as Kandana just mentioned, that's a new release Azure provided to simplify most of the deployment work. And then for Cloud Foundry, I think that Cloud Foundry is a good candidate to utilize this technology to simplify user experience. This can be accessed through both the portal or you can do it through scripting. Usually, it's simply three steps. First, you load an existing template we already defined for you, and then you customize it using your organization name and your parameters. And then you deploy it. It was just running on the background. And then all these can be automated. So here, I'm going to show you how we can use a template to set up the Azure environment. It will take a while, so I will mostly go through the UI steps. And then with an existing Cloud Foundry deployment, how we can push a simple first application. So first, this is the Azure Quick Start Template website. From here, there are hundreds of predefined templates. You can see if you can just click any of the template. What it will tell you is it will display the parameters you need for this template. And it will also show you how you can launch or scripting this. There's another button that will take you to the UI, which you can edit this template. This is one way to start your template. And there's also the other way is you can go directly to the GitHub. This is the GitHub. It contains all the source code for this template. And you can always give your feedback or your pull request here. And again here, it also has the parameter for this deployment. For this one, this is the Michael Bush deployment template. So it asks you for some minimal information you needed about the account name, account password, and the VM size location. And here it also have a button to take you to the UI that will allow you to edit your template. So here we get to the UI that you can edit your template. This is actually the source code of this template. We have documents on these very simple syntax for you to edit. And at the end, you will see all the resources that's added. And you can add, remove, or modify the settings of your template here. And then you save it. Once you save it, you can edit your parameters. And here, what you needed is you need to create a new storage account. Here I give a C. And since we also create the developed machine for you, we need admin username and password for this machine. And you need to choose where you want this VM is put, located, and then the VM name. So you save it. This needs to be created under existing subscription. So you select your subscription. And for this resources group, you can either put it under an existing resources group name, or you enter a new name. And we also need to select a location. So after that, after you enter the template parameters and choosing the right location and names, you just click Create. And then it will just create this template at the background. So it will take a few minutes. To save the time, I can show you one of the template resources I already created. So this is the resources group I just created just using the same methodology. And then it's already created with the machine that we created, the depth machine with this network interface, and the public IP address, and the virtual network, which contain the two subnet and the storage account we need. So with this, you will be simply just go through a UI, enter all the customized parameters, and then, one click, you will be able to create an agile environment that you can build your Cloud Foundry on it. So after this, the next step is on your depth machine, as we said, on Create Michael Bosch, Create Bosch, and then through Michael Bosch, create your Cloud Foundry network. And these steps are all standard. So here, I have one Cloud Foundry machine I already created. So we'll just SSH to it, and we'll see how we can push a simple application. So while we wait for that, right, the template is only one mechanism to do it. You can also do the same thing by directly calling the Azure CLI, which is the command line tool for creating provisioning resources in Azure. So here, I'm SSH to the Cloud Foundry VM. And for this VM, just logging, we already have a simple application here. And you can see that we have a JS file, which created a first website on the Cloud Foundry. And let me just log into this. Now I'm logging to Cloud Foundry, and I need my username and password. OK, now I just get into access to Cloud Foundry. And then I'm ready to push the first application now. So you see, now it began to install and compile and build the application and put it to the appropriate host. So the instance is starting. Seems to me it's successful. So go back to my website. This is the website that no JS application just created. And let me see. So this is the first message that application sent to Azure. Hello, Cloud Foundry. OK, so that is the demo of the template and how the first application is pushed on Azure. Back to our message. Learning from the Cloud Foundry projects. So this is actually a totally open source project. And we are an open source team in Microsoft. We have people from open source, but we also have a lot of people like me working in Windows for many years. So it's a good journey and a lot of good learnings. And I think the biggest thing is we are amazed about the power of the community. And this project actually originally started by the community. And we have Nick Terry, who is the first community member to start this project. And all our code is built on his original work. And also Dimitri, who is along the time, always give us support and guidance, give us regular reviews. And we really want to thank Nick and Dimitri. Is Nick and Dimitri here? OK, I hope they are here. But also everywhere in the community, we really appreciate that support and help. And we also feel this structure, this Cloud Foundry and the CPI structure is very well designed and flexible. The integration actually is very smooth. We didn't hit a lot of big blockers. And after that, we find the experience is also quite similar and transferable between different cloud providers, which is, I think, is the big benefit of the portable structure. And the abundant resources and the agility in the community, which we are really impressed. And we also learn to align our internal goal with the community goal. It's not like a program manager used to control the schedule and control our priority. But now we are working with the community. So we know how we are not only creating a commercial project, we are also part of the project, the community. So this is also our priority to enhance the community and give back to the community. So that also reflect into our schedule and our priorities. The challenges, of course, are all the moving parts. And although before, in Microsoft, I feel like we have a lot of control over the versions and then when we can make change, when we can stabilize. But right now, when we're working with community, we probably only know whether the things worked and how the competitive works until we test. And especially when building the storm cell. And you will find you have a stable build. You have a stable dependency. But there are still changes, for example, even coming from the OS itself. So it's a big learning, but this is the part I know I see the community. That's the part that you gain the benefit of the community but also the part that you have to take the challenge for. But I know community is improving on this. And we are currently moving to our external CPI model, which will make the CPI be more transparent and less dependent on Bush. So this will make our build more stable. Actually, this is our goal for Beta. We'll move to there soon. Yeah, this is actually a very exciting milestone for us. On two counts, one is not only this is the first time Cloud Foundry has worked completely end-to-end on Azure. And second thing is this is the first time from Microsoft, we have come to this conference to talk about it. So really exciting milestone for us. So all the work currently, the binary country is available on GitHub. And then we'll give the link at the end of the slides. And at the end of this week, at the end of this, actually this event, you will be able to preview this. And we will have the document, we'll have the blog. So this is the first step. And then, but at this time, we are not going to declare the beta yet, because we want to move to the external CPI, which the community recommend us to do. That probably will take us to around the end of May. And at that time, we will have an external CPI stable build. And then we will send the bits to the Cloud Foundry DL, which the distribution list, so that everyone can try and use the DL to discuss about the issues or questions. And then our next goal is upstream to go back to the community source depot. So this will be our GA. So once we get the community fully approved, and it will become an official community supported project, we will declare the CA, and then declare the GA, and officially on supported onboarding to Azure. And then the four and five are the next step. We know once you get the deployment, once people hit the part, they will do the daily operation and the configuration. Then they will have a lot of questions on how this works on Azure, how those open source software, like different database or low balance on how that work on Azure. This is supposed to be quite transparent. It should work between different cloud providers. But we also want to work community to see your feedback, to see if there are anything we can optimize and improve. So here is the link. You can click, and then you can find the first version that will work. And probably at the end of this week, it will have a blog, and it will have a documentation. Currently, it doesn't have a documentation yet, and we'll upload the guidance. And then you can also use GitHub for your feedbacks. OK. Yep. Thank you so much. Thank you.