 So what are you going to get out of this session? So we're going to cover a little bit of sort of learnings from standing up SAP cloud platform on Azure and using that as a case study for multi-cloud. But before we get into that, I'm just going to give sort of a brief overview of what Cloud Foundry on Azure means and kind of what the scope of it is. And then talk a little bit about sort of how you can get involved and participate in this journey that we're on. So what is Cloud Foundry on Azure? So this question comes up a lot because there's apparently still a lot of people that believe that Azure is sort of just the Windows Cloud, you know, it's only for doing building dot net applications with Visual Studio targeting Windows to run on Azure. And so people go like Cloud Foundry, that doesn't seem like it would align very well. Azure has changed, Microsoft has changed significantly and Azure has been sort of at the up leading edge of that. We've actually been working with the Cloud Foundry community and with a number of partners for about three years now to bring Cloud Foundry to Azure in a number of different forms. So we have the fully open source version that you can run on top of the Azure infrastructure. You can deploy the Pivotal Cloud Foundry in a sort of single tenant version inside of your Azure subscription from the Azure Marketplace. Or as we'll be talking about today, you can use the fully hosted multi-tenant service from SAP. And as a result of all that work that we've been doing and the partnerships that we've been working on, we actually announced at the Cloud Foundry Summit in Silicon Valley in June that Microsoft had joined the Cloud Foundry Foundation, so really putting a bow on all the work that we've done with Cloud Foundry. And the reason for it is ultimately that we want Azure to be the most open cloud. And so we want to make sure that any operating system you want to target, any framework or tool chain you want to use, any platform you want to use, including things like Cloud Foundry, that you get really a best in class experience on top of Azure. And so that's why we really put a lot of resources into that work. So with that, I'm going to call on Dmitry to talk a little bit about what SAP thinks about in terms of multi-cloud and give a little bit of background on that cloud platform. OK, so as you know, the cloud computing today is an often preferable direction for running software. And as its usage grows, the idea of multi-cloud is gaining more adoption and spread. People are asking me if I could explain a little bit what is the mention of multi-cloud and why it would be important to them. So because multi-cloud have a very broad definition and its response to different topics of cloud architecture and response to modern businesses and developer needs, it's better to explain it with some examples. For enterprise, a multi-cloud that could be a strategy that allows an enterprise to run their software where they best fit by using several cloud providers as one single solution. It allows the enterprise to meet a specific application requirements or a specific workload by consuming multiple cloud providers. And while just as long as each provider can fulfill enterprise specific needs at a given time. Another example, IT specialists may find a multi-cloud as a solution for reducing the risk of downtime or widespread data loss caused by a localized component failure. And of course, and surely the developers may use multi-cloud as an enabler to consume unique innovation technologies from different cloud providers to build great apps. So let's do a very brief overview of the SAP Cloud Platform to understand what is the role of the multi-cloud and the cloud foundry for SAP. SAP Cloud Platform is an enterprise platform as a service that offers you the flexibility to use the leading cloud providers. So while you may select infrastructure powered by Amazon, which is available in general availability, you can also select Google Cloud Platform and Microsoft Azure as an additional infrastructure and thus cloud providers available as a public beta. Regardless of which cloud providers you choose, all multi-cloud application deployments can be centrally managed and operated in one single unified cockpit. Use of adoption is very important to us. So SAP takes care of the complexity of managing and operating the underlying infrastructure accounts. So you can quickly move the applications to the infrastructure that best meets your requirements with a limited effort. If for some reason the application needed to go to another infrastructure, you can easily deploy your application to SAP Cloud Platform and another infrastructure. And to recap, for SAP Cloud Foundry, it plays a central role in a platform as a service strategy. Offering the Cloud Foundry environment helps grow SAP Cloud Platform commitment to open standards and open source technologies and provides more option to developers to utilize the richness of our platform. So Cloud Foundry allows SAP and SAP customers to use popular programming language but also to deploy applications on top of popular IS platform, hence no vendor lock-in. OK, thanks. And now Sean will talk about Cloud Foundry on Azure. All right, thanks, Dimitri. Hey, it's me. I'm back. So I talked a little bit about Cloud Foundry on Azure sort of conceptually a little bit deeper, although not too much deeper. For those who are familiar with Cloud Foundry, this picture will be fairly familiar to you. If you're new, just to give you kind of a sense of how it works, we've got the base Azure infrastructure kind of at the bottom layer. That is deployed using the Cloud Provider Interface plugin that we provide, so the Azure CPI for Bosch. Once you have that Cloud Foundry environment deployed, then you're deploying your applications onto Cloud Foundry, and you actually don't really need to worry about the fact that you're running on Azure. You're just using Cloud Foundry, and that's sort of where this whole sort of multi-cloud abstraction comes in. That's to sort of run your stateless applications. If you want to take advantage of some of the Azure backing services for storing some of your states, that's where the Service Broker API comes in. And we'll talk a little bit more about that in a bit. We've built the Azure Service Broker API as a way to connect out to Azure platform services, so some of our more popular services like Azure SQL, Azure Cosmos DB Storage, and our recently announced MySQL and Postgres databases as a service. Look at that transition. So the session is entitled Making It Real, so I think to make it real, we have to get out of PowerPoint just for a brief second. And I want to just kind of give a sense of how this looks in practice. So I mentioned the Cloud Provider Interface that we build. This is developed by Microsoft Full Time Engineers. We do it fully in the open on GitHub. So this is the project that we've been working on for, again, roughly the last two and a half or three years, have done, as you can see, 27 releases and continuing to add more functionality, integrate with new features that come out in Azure. So as we announced our managed disks offering, for example, we added support for that in the CPI. We recently integrated it with the Azure Application Gateway, which is our layer seven load balancer. And so if you go in here, if you wanted to deploy Cloud Foundry, sort of the fully open source version, you could start from here, jump over into the Bosch documentation to set up your Azure environment, and actually the easiest way to get this bootstrapped is if you go here into the Azure Quick Start templates in GitHub linked there from the Bosch documentation, this actually provides the Azure Resource Manager template that's required to stand up the Jumpbox VM, all the virtual network and storage resources that you need to be able to deploy your Cloud Foundry environment. And the nice thing is you can go right from here to the Azure portal and basically fill in just the necessary properties to stand up that environment. So this makes it pretty easy to get an initial Cloud Foundry environment set up on Azure. You'll see, you fill in some of the details you need here and you'll notice that there is an option to, this will set up initially just sort of a Jumpbox on a virtual network in Azure that you can use as you sort of your entry point to your Cloud Foundry environment and you can actually set it up to also deploy the Bosch director. So to get you up and running and once you do that, you will get a VM that looks like this where you'll get a set of resources and scripts and Bosch manifests that you can actually use to deploy Cloud Foundry. So like under manifests there are options for deploying a single VM, multiple VMs. This makes it relatively easy to get started with running the fully open source Cloud Foundry on Azure. Now that being said, there's still a certain amount of work here to bootstrap this environment. And so that's where using something like the SAP Cloud Platform comes in to allow you to get started even easier with a fully hosted service. So I'll turn it back over to Dmitry to talk a little bit about the technical details of the Cloud Platform. Please don't worry if you find this picture slightly complicated. I'm not going to talk about Cloud Foundry architecture, about Cloud Foundry architecture, about all the services and all the components you can see there. Actually, my story is about how we made the multi cloud to become a reality for SAP Cloud Platform on the case of Microsoft Azure. So in the beginning, we just started with a blueprint like that. And then after a few months, we have finished with a successful integration of Microsoft Azure into infrastructure providers family available on SAP Cloud Platform. So first of all, I want to share the general impression from our work with Microsoft Azure. When we started our exploration of Azure capabilities, we discovered Azure as a stable and mature IS. The lot features and functionality required for our platform, we're already there from day one. For example, things like wide offering of the VM and the hardware types and series. For us, it was important because every component that you can see there, is a consumes a specific amount of resources. Hence our role is to find the optimal match between the component needs and the provided IS resources. And of course, we have found ready to use the Terraform and Bosch CPI for Azure. Such readiness allows us to do a rapid delivery of SAP Cloud Platform and SAP Cloud Foundry on top of Microsoft Azure. You can find that Cloud Foundry on the diagram is one of the pillars in the overall SAP Cloud Platform architecture. It's consisting of multiple components communicating with each other. I want to put your attention that in order to run it on top of Azure, we have collected all the requirements needed for the Cloud Foundry environment and also for all the SAP services and then found the relevant counterparts provided by Azure. For us, it's a fundamental to consume all these resources using the Terraform and Bosch CPIs. My colleagues work closely with the Microsoft team to enhance Bosch CPI and to address essential functionality needed for SAP Cloud Platform on Microsoft Azure. And also last but not least, in the big data area that you can see there, we are working together with Microsoft to certify HANA machines for general availability. So I think it's a good moment to show a small demo of SAP Cloud Platform. You can scan this QR code to go into our Cloud Platform cockpit and actually let's go into it. So actually this is in our cockpit because our demo is limited in time. We have a very strict time limit. So I will skip the registration process for you and we'll go directly to the detail. So after the registration, you can get into this dashboard where you as a developer can use the Cloud Foundry environment for deploying your applications. And for example, you can see that we are providing several Cloud Providers in different regions. And for this demo, especially, I created a project, a demo project on top of Microsoft Azure using the Azure infrastructures. So after I created my account and created the project, you can get into the account overview where you can find all the relevant information like what is the name of the organization, which quota and which services you have, the API endpoint, and if you go deeper into the menus, you can reach the marketplace where you can find the common back-end where services that we are providing and other services like the application works, the HANA trial, under common back-end where services, I mean the PostgreSQL, the RabbitMQ, Redis, and other databases. So for example, my application consumes the PostgreSQL database. So I created an instance of the database and deployed the application. And also after I did the deployment, I did a binding of the PostgreSQL service to my application. So for example, after you do the binding using the dashboard, you can also go to the database or service-specific dashboards. For example, if I'm clicking here, you can see that it's all the details, all the properties, the application log. And if you are familiar with the terminal and you prefer to operate with Cloud Foundry using the Cloud Foundry CLI. So for example, you can target the environment at API endpoint. And for example, you can get the application and I can see the services. So for example, if I open the application, so it's just a very small application that should demonstrate the basic functionality of SAP Cloud Platform. So let's see what's happened under the hood. How was this done on Azure? So briefly on this side, you can see how we are doing of the deployment of the Cloud Foundry environment in other services on top of different Cloud providers. You may find in our toolbox, we are using the tools like Terraform and Bosch and also we are using the concourse for continuous integration. The central role here is it belongs to infrastructure as a code. It's a method to define infrastructure components and all their requirements in form of code. It could be a Bosch manifest or Terraform script for example. So when developer changing the code of some component and commits it to the repository, then the concourse may trigger a Bosch deployment with a specific manifest to do a component update. Because not all Cloud providers may the same, hence the challenging is to support all the diversity of Cloud technologies and the difference between Bosch CPIs, dialects. So when we are deploying the Cloud Foundry environment, we are managing all those differences to provide the same Cloud Foundry experience for customers, regardless of hosted infrastructure. So my story would not be complete without talking about multi-Cloud challenge on Azure. So as a support of different Bosch CPI dialects is a general challenge, I would like to talk about other kind of challenge but of the same level. While the capabilities of Cloud providers are mostly similar, often they are organizing the resources and differently in order to provide to those capabilities. So actually the great example of how different Cloud providers are complex, the same goals with a different design is availability concepts. On most of Cloud providers, users are ensuring availability by spreading multiple instances of the same VM role across availability zones. In other words, each zone is a represent the distant fold domain. For example, if I have a web service and I would like to have a high availability, so I may deploy at least one instance at each zone and I have to do it manually. On Azure, in contrast to other Cloud providers, users can place multiple instances of the same VM role in availability set and allow the Azure platform to automatically spread them across four domains. They say, pick out platform abstracts these differences away from you. Okay, so when we started our exploratory of Azure capabilities, we have a concern about the ease of operation of multiple storage accounts and about the overall disk performance using classic storage accounts. But everything changed with the managed disk feature release which removes the performance limit boundaries. So all concerns will dissipate after the general availability of the managed disk and the following update of the Bosch CPI that support this feature. And if I'm talking about Bosch CPI enhancement, it's a good idea to show how the Bosch CPI evolves over the time. Please put attention that most of the major updates will deliver it in a short period of time. For a half year, a new Azure functionality support landed into Bosch CPI, like managed disk feature, multiple research group support, ability to create application gateway and all other overall improvements towards developer experience, like better diagnostics or retry logic. So I think it was a very fantastic work and I think it's perfect to my story. So thank you. And now Sean, we'll talk about SAP Cloud Platform and the native Azure integrations. This is like a performance test for MacBook HDMI connectivity. Okay, so Dimitri talked a little bit about some of the challenges that we work through together to align SAP Cloud Platform's multi-cloud architecture with some of the specific design decisions that we've made in Azure and how the cloud platform ultimately abstracts most of those things away from you. So you don't have to worry about those sort of peculiarities of different cloud providers. But then there are a number of cases where you actually want to take advantage of some native capabilities and you want to have awareness of the cloud provider that you're running on so that you can actually use some of the differentiated capabilities. And so there's a couple of those that are of interest when it comes to Azure. The first is briefly mentioned before the service broker concept. This is something that I think everybody in the cloud founder community is very excited about. In fact, is growing now beyond cloud boundary into Kubernetes through the service catalog work. And so in Azure, we've built the Azure service broker that provides access to some of our most popular backing services as I mentioned before. And so you can deploy that in any cloud foundry environment including the cloud platform and use that as a way to connect your applications, your sort of cloud native 12 factor apps running in the cloud platform to stateful backing services that are running in this case in Azure. And I'll show an example of that in a second. The other is Active Directory. So Microsoft has a huge amount of assets in the identity space with Active Directory on-prem as well as our hosted version in Azure, Azure Active Directory. And so we've done work as part of that sort of ongoing work with cloud foundry to make the Azure Active Directory service integrated with cloud foundry which means that you can have your, if you have your identity, your corporate identity already managed in Active Directory and potentially federated into AAD. You can use that as your identity into your cloud foundry environment as well. So you don't have to create entirely new developer and operator identities for managing your cloud foundry environment. You can use that with the cloud platform as well. And so that's quite powerful because you can then do a single sign-on into all the different products that AAD supports including Office 365, for example. Okay, so let me jump back out of here again and do a quick demo of the Azure service broker. So again, I'll start in GitHub because again, this is a similar to the CPIs, a project that's built by Microsoft full-time engineers with contributions to the community. We do it all out in the open in GitHub. And so you can take a look here in this GitHub project and see the services that we support today. So I think there's like nine services that we provide there and we're continuing to add more all the time. And so what I'm gonna do is take advantage of this service broker to actually deploy a back-end service in Azure that I can then connect up to an app that's running in the SAP Cloud Platform. So I'll do this actually through the Azure Cloud Shell which is our in-browser CLI experience. So this gives you a full bash shell actually running inside the browser. And I mentioned we've done a number of things to integrate Azure with Cloud Foundry and one of them is we've actually pre-installed the CF CLI in the Cloud Shell. So anybody that has an Azure account can use this for free. So if you're ever sort of on the go and need to access your Cloud Foundry environment whether it's running in Azure or running somewhere else if you just need access to the CF CLI in the browser you can use this. And so what I'll do is I'm basically I've already logged into my Cloud Platform environment and you see here that I'm logged in with my corporate identity. So that's taking advantage of that Active Directory integration and I've already deployed the Azure Service Broker which just gets deployed as a Cloud Foundry application. So you can take that project that's available and get hub and deploy it as a CF app into any CF environment. And as a result, if I do CF Marketplace I can see all of the Azure Backing Services that are available to deploy here alongside some of the ones that are provided natively by the Cloud Platform. So here's Cosmos DB and Event Hubs and MySQL and so on. And so what I'm gonna do, I've got a simple Node.js application that relies on a Redis cache. And so the beauty of the Service Broker is kind of just as a developer you say I just want to have a Redis cache from somewhere I don't really care where it's coming from. In this case I'll use the one that's available in Azure. And so I can just do CF Create Service. Give it the name of the service. Add our Azure Redis cache. We'll call it CF Summit Demo. Whoops, where did I miss here? Oh, the plan name. So I'll use the basic plan. Try to save a few francs. And so what that's gonna do is actually talk through the Service Broker app to start deploying a Redis cache in Azure that I could then bind to my application. That's gonna take a few minutes that we don't have. So I'll use one that I created earlier which you can see specified here in the manifest, the CF Redis demo service. So if I just go ahead and push this application. So I'm pushing this app into the cloud platform. So it's running in the fully hosted environment provided by SAP, but then it's binding to this Redis cache service that I've deployed into my Azure subscription. And once that's completed, I will have a my Node.js application that can talk to that Redis cache behind the scenes. And there you go. It's all up and running. So if I go ahead and grab this endpoint here, put that into a new tab, you see this app. I'm available for consultation on web design after the talk if anybody needs help. So we'll just say CF Summit, let's say SAP platform. Rock submit that and that's going to get stored as a key value pair in that Redis cache behind the scenes. And as you might expect, I can pull it back. So that allows me to take advantage of some of those native Azure services in conjunction with the cloud platform managed by SAP. Okay, so let's start to wrap up. So Cloud Foundry on Azure is again something we've been working on for multiple years. We've got multiple different ways that you can interact with it. We think the cloud platform from SAP provides a great way for customers who are looking to either integrate with their existing SAP assets or have that sort of fully hosted, fully managed service where you don't even have to deal with setting up your boss director and that sort of thing. We've worked really closely with SAP over the last year so to get the cloud platform up and running on Azure it's been a really great partnership as Dimitri alluded to. We've had really quick iteration cycles between the two companies and we're really aware of and invested in this multi-cloud notion. We hear this from a lot of customers and so it's not something that we fear to go and have these conversations about how we can enable multi-cloud environments like the cloud platform. And as a result, Cloud Platform is the first multi-tenant hosted Cloud Foundry offering in Azure. So that's pretty exciting. A bunch of resources here including some of the things that we pointed to through the session. So go ahead and check those out. And with that, I think we'll open it up for a few minutes of questions. Thanks very much. This is one in the back first, yep. Pardon me. The resources, sure. You should be able to get this deck afterwards as well but there you go. Yes sir. The upgrade of Cloud Foundry basically within the Cloud Platform, right? It's a version of Cloud Platform because it's open source Cloud Platform today. So you have quite a release version and then there's a new release version. Actually we're constantly updating the Cloud Platform versions. We are doing it in sequence. So for customers, the transition is very transparent so as a customer you don't need to care how and when the version is updated because we are doing it transparently. And I think it's typically like within a couple weeks, right? Typically within a couple weeks of like sort of an open source version being. We have a release cycle but we may talk about it in the offline. What is the backup and restore of that? The backup and restore of the... I've been working on it and I think it's better to talk offline and you can find me at SAP Fools and we can talk about all the real questions. Okay, thank you. Yep. Yeah, so can you believe me that I botched on as you don't stop trying to work people? Yes. So that was the thing I showed initially is basically you go to the Azure CPI GitHub page or actually the botched documentation and that gives you the, I think one of these links will have it, the instructions for deploying basically a boss director so you can use Azure Resource Manager template and just spin up the Azure Virtual Network and a couple of virtual machines, storage accounts, about a dozen resources to get created but then you can deploy open source Cloud Foundry. Yeah. Correct, yeah. If you wanna run open source Cloud Foundry you're running that directly on Azure IaaS resources that are part of your account, your subscription. So Cloud Foundry is not built on VM scale sets, Azure VM scale sets because Bosch operates in terms of single VMs. We actually, we did a whole investigation about whether we could enable that but it just doesn't work well with the Bosch API but in general, yeah, you get the capabilities of the core Azure IaaS in terms of you can choose different VM SKUs and you can set them up for shutting down and all that kind of stuff through Bosch deployments basically. It's, yeah, that is, it's one of the drawbacks frankly is that we don't have, I mean, Cloud Foundry in general doesn't have an auto scaling, infrastructure auto scaling notion which is again, I think, you know, part of the value of using something like SCP is that it's just sort of auto scales for you. Okay, yeah, so thanks everybody for coming. If you have any questions about Cloud Foundry and Azure I'll be at the Microsoft booth most of the time over the next couple of days and as Dimitri mentioned, he'll be over at the SAP booth so thanks everybody. Okay, thank you. Thank you. Thank you.