 Welcome everybody to the California Summit Session Hitchhiker's Guide to the Enterprise great platform. I am from SAP, but still panic. We think it's okay. So I was just told by a colleague I forgot the most important thing. It's actually a towel. So in the Hitchhiker's Guide to the Galaxy, the towel is the most important asset you can use. But that's not what we want to talk about today. So I'm Gwinnigera. I'm working in the broad management of a past offering from SAP, the HANA Cloud Platform. And what I want to talk about today is actually share with you SAP's journey in the Enterprise great platform and how Cloud Foundry also plays a role here. What kind of challenges we have faced with regards to speech. That our customers demand multi-clouds that we already heard quite often already even now that the Cloud Foundry Summit started just right now before this session. Another one about multi-cloud deployments. Very important for us security topics that we also with Cloud Foundry and the very prominent other topics part. So where I will talk about other topics. So before going now into the challenges that SAP faced, let me just explain briefly where SAP is coming from so that you also understand what our strategy is. So SAP is focusing on business applications for quite some time. So since 1971, so as old as I am. We have, yes I know I look older. We have around 20,000 developers in research and development at SAP and our goal right now is really help customers with their digitization that we always hear around IoT or in Germany Industrie 4.0 which is something totally different than IoT. I'm just kidding. And if you hear SAP normally you don't connect it directly with cloud offerings, right? But we're not really new in the business so I put here some dates about products we have in place for different purposes. So we started with success factors of company we acquired around human capital management, a rebar for business networks. 2012 we came up with our own platform as a service offering for tackling the requirements from our customers so our own paths with the HANA Cloud platform. And then it goes along. Hybris, Conquer, SAP S for HANA. So another business suite completely in the cloud and I mean while you are seeing this and also maybe with the history, who of you knows SAP at all? Maybe just raise your hand. I always make a test question. Who of you didn't know SAP before? Could you also raise your hands? Okay, who of you didn't pay attention to my question? Okay, good. So I mean coming from a company that is also known for mostly on-premise applications so we had a long way and also had to evolve with regard to how we were set up and how we worked, right? So I put here just some passwords but it really means a substantial change also in how SAP develops software, right? So we came from a waterfall model to agile development and are going over to DevOps, right? In our applications we are moving away from creating this big SAP monolith with a lot of power and cycles of one year or release cycles of one year or half a year over to microservices and also deployments of our products on bi-weekly basis. And we are keep on changing from physical service via virtual service over to containers and then also now container frameworks and the journey keeps on going, right? From a data center to hosted environments to cloud environments that we have to set up really to also tackle the requirements again from our customers that they have to run their businesses. And a lot of work also moving from proprietary tools that SAP develops over to usage and contributions to open source and standards. So quite a long way. So what do we need to ensure during that journey? So our customers of course still want to run their business on top of what we are doing. But they want to have, of course, everything should be still fast, secure, so exclamation mark, secure, scalable, non-disruptive. So you don't want to use new stuff, right? And suddenly your business that keeps your business running stops working because SAP has done an upgrade. You don't want to have that. You want to support 24 by 7 every day and also ensure and ensure, depending on the requirements, also from different industries, traceability of everything that is done, auditability. So whenever changes are done in the back end, changes are done in the database. You need to know who has done it, who has access to these systems. Certification is also a big topic, so you need to have certain certifications for certain industries. And while doing that, what do we do? So we try to focus really on those parts of our technology which we feel is differentiating compared to what others are doing and really engage in standards and open source to leverage what is out there and also to contribute back what we think is also useful to the community. And we have a lot of learnings from that, right? While doing this, there's a lot of stuff. So there you have multiple options. So either you let others have the same experience. I put a quote here from the Hitchhiker's Guide to the Galaxy. I've just had an unhappy love affair, so I don't see why anybody else should have a good time. Or you try to be a good open source citizen and contribute back your learnings and share it with others so that they can leverage that. So, but we don't do it that stand alone, right? Just contributing for contributing. It's rather a strategy around co-innovation, open source and standards. So we try to learn from customers what they need. So tomorrow there will be also a keynote from Mark Gil, responsible for partnering at SAP, and you will learn there also what we are doing, for example, with Siemens. So who of you did watch today the keynote from Sam Ramji? Okay, now again the test question. Who of you didn't? Okay, so good one. So at the end of the summit, Sam put Siemens on one slide, right? So with their IoT platform, MindSphere. So that platform, for example, was built together with SAP, and we are using that co-innovation with the customer to really know what are the requirements from big customers in the IoT space, and to learn from them what they need and then to incorporate this into our products. Also maybe using partners to join the efforts and then actually contribute technology that we feel is useful to the open source community, back to the open source community so that people can leverage, they can even bring more requirements into that and then concentrate on what is actually differentiating us from others. And just to put here some numbers of contribution or total number of contributors, that's this bluish line here. Is it blue? I have color difficulties. It is blue, right? So something around 30 contributors we have right now, so we learned today how much contributors do we have at the Cloud Foundry community. Anyone paid attention to the number from Sam? Who knows, remembers? 130, right? So although you say, well, we have 20,000 developers in research and development and only 30 are contributing to Cloud Foundry, but again, I mean, we are trying to use the platform and to fill it with the requirements from our customers and partners and building up on that, right? And we didn't reinvent another platform as a service offering, right? We are taking now Cloud Foundry, which is already a very rich feature set and try to leverage there and contribute back what we feel is also useful for the community. Okay, so now trying to go back to Cloud Foundry. So what are our learnings, for example, with regard to speed? So when setting up a Cloud Foundry instance, you are wondering, okay, how to set this up in a fast way? And for that, we actually worked on something we called Service Fabrik. So it's written with a K. It's no typo. It's a German Fabrik. Yeah. It's not English. It's German and English. It's both, not pen parallel, right? So what are the challenges that we faced when now setting up a Cloud Foundry instance? Normally, you don't have any default services up and running off the shelf in Cloud Foundry. So every provider needs really to take care of that, to set this up in a fast way so that you can provide the services either to your fellow colleagues at your company or to your customers and partners. And also, the Service Broker API doesn't really help you a lot with provisioning technology. It's very open, right? But with very open, it means it's very flexible and with very flexible, you can do whatever you want. But yeah, it's difficult to find out what you want, right? If there is nothing that you can take to copy and paste. It's also necessary to have backup and restore capabilities built in, which are not available yet. So it's something that we struggled with, that we need to also provide to our customers because they have very high requirements in that area. And also, the Cloud Controller model is really very minimalistic and doesn't provide you any means for version control. So our requirements for proper solution were to easily set up backing services so that ideally you just click on the button or run a command. It should be inexpensive for development and testing. Of course, reliable, isolated, and in a high availability cluster, usable for productive usage, quite important for us so that it's not just a test environment which actually works, but it's really something you can also deliver to customers. Yeah, focus on a few provisioning technologies to ease the development and operations of these components, provide backup and restore, and also to provide the possibility of having multiple versions of your services available and simply select I want to have this version or that version in my offering, and that's it, right? And for that, yeah, we worked at SAP with the service fabric, with Kay, remember, it's German, to provide now a generic service broker and the Bosch release. It supports provisioning on Docker and Swarm, and there is also a possibility to use existing Docker Bosch releases with the service fabric. There is also a very generic dashboard available that you can use to find out, okay, what is the URL of my service, what is the user and password, so something very basic that you don't have to do on your own, which you simply can reuse. There is also the possibility to have an automated step-still and release update, so whenever you find out there are, for example, some security issues, some security breaches, that you can vastly exchange them in an automated way. Also providing you with a possibility to backup and restore, and we provide that with a service fabric right now for OpenStick and AWS, it's on its way, and we are also open to other layers underneath. And there is also an operations tool available, and for those of you who want to try out, so it's available on GitHub since a few days, github.com slash SAP service fabric broker. And I'm just checking the time. Okay, are you still awake? Who's awake? Okay, who's sleeping? Okay, good, I will try to hurry up. So I put here a little picture to a very nice picture, which of course you'll understand immediately, but just to explain a little bit, so the service fabric broker is providing you here an extension to the cloud controller and also the possibility to actually add a plug-in to your command line interface, so that you can also use the service fabric directly via the command line interface API, so extending actually the API. And then underneath you see here the different provisioning models that you can use then for either Docker instances or putting here the services on Bosch. So while we were talking briefly about the infrastructure as a service layer, I find it quite interesting when I was discussing with the colleagues who are working on another project called Cloud Foundry. Any of my colleagues here who knows? If not, come to the booth and I will try to get the right person. I'm not the expert in all of these technologies, I can't tell you. So what I found interesting when looking into the infrastructures that there is a nice, it's not a quote from the Hitchhiker's Guide to the Galaxy, but it's actually from the OpenStack documentation on Cloud Foundry saying the requirements, so to know whether or not your Cloud Foundry installation runs, for example, on OpenStack, the requirements listed here are considered necessary but not sufficient for Bosch to be able to use your OpenStack deployment. If you cannot perform any of these tasks successfully, Bosch will not work. However, satisfying all these requirements does not ensure that Bosch will work. So it's either so you stick to what is necessary and then you think you are fine, but no, it's not. So meaning while validating the infrastructure, you might find out that it doesn't work. So the challenge is that SAP also wants to run one Cloud Foundry installation in various data centers The question is, will now this installation run on the customers or partners OpenStack distribution? And if you're using the tooling which is available right now, you have a very hard time to understand the errors messages you're getting back from Bosch, so you need to have a deep Bosch expertise. And what we wanted to have is actually the possibility to have no deep Bosch expertise for that. It should be easy to use and also have error messages with actionable descriptions, right? And for that, we have also open source the Cloud Foundry OpenStack validator, and it actually will respond to the question, will it run on my OpenStack installation? So there is an executable and also a configuration file that you can set up for your Cloud Foundry environment. And you will actually get also actionable hints also for non-Bosch experts. Let me try if I can increase. Yes, I can. I love my Mac. So these are the error messages you get, for example. Your OpenStack using the CPI can create large disk. Large disk could not be created. So it tells you if you are using DevStack, you need to manually set a larger backing file size in your local RC. So underneath also another failure, right? So you're getting really actionable hints on what to do to avoid these error messages or to make the environment actually work on your site. So another... I'm doing okay with the time. Another source of surprises, also security. So another quote from Hitchhiker's Guide to the Galaxy. Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws. So SAP as well, all the customers and partners who are running their businesses, they don't like risks, right? And with the Cloud Foundry setup, you might get into the issues that attackers might be listening to network traffic between the nodes, right? And if they have the right tooling, right, they might get maybe passwords, user names going between the nodes. So what we wanted to do is actually to encrypt all the traffic between the nodes so that even if the attackers are listening, that they just get gibberish or Portuguese or whatever, so things they don't understand. If there is something which... although you took care of it, really drops or doesn't work anymore, or there is a security breach anyways in this encryption, that you can dynamically reconfigure it so that without a downtime, you just set up another algorithm and then the security breach is closed. And also it should have no impact on scalability, meaning if you want to run this in multiple instances so that this encryption doesn't really hinder you on scaling broader, so it doesn't need a lot of resources. So that's why SAQ came up with the Bosch release for IPsec. So it actually is doing exactly that, so encrypting all the communication inside a Cloud Foundry deployment between the nodes and can also be used as a core deployment, right? And it actually works in a way that it's using encryption on the kernel. Just to get that right, are you referring to IPsec as the network protocol or is that another term that SAP captured? No, it's a network protocol that is available as a Bosch release that you can take then and deploy then in your Cloud Foundry installation. So it is using what you know from IPsec also in the Cloud Foundry setup. So it's IP protocol, I don't know, 5.0 as specified 20 years ago by the IETF. Yes, exactly. So you're using what is already existing in the Linux kernel. Okay, now the legendary other topics, things that we also are working on and identifying how to actually leverage that also for the Cloud Foundry community. So we are looking into lifecycle management of applications. So we are currently trying to define a standard for creating these package Cloud Foundry apps so that you can deploy them in different locations. I think Sam also talked about that today in his keynote. And you should be able to actually take these applications and deploy them on any of those Cloud Foundry certified platforms. So that's the idea. We are already using it inside SAP for blue-green deployments to ensure that there is always a productive system up and running. And we are currently finding out how to bring this now to the foundation and actually do a co-development with the community. What we are also currently ramping up along with big partners with IBM and Orange collaborations around autoscaling and autosleep of applications. So put in here the GitHub links to these projects. So again, not trying to reinvent the wheel again, but instead getting bigger partners into the boat, also getting their requirements into our standard and then really leveraging that and contributing back to the community so that others don't have to go in to discuss again or think again how do we do an autoscale on Cloud Foundry, how we ensure autosleep to ensure we don't spend too much money on putting machines up and running on a landscape which really costs us money, right? So trying to put here a standard in place that others can use and last but not least also working in Diego and Abacus around metering and the Diego framework, putting here also a number of full-time committers that are working on this. So also trying to push what is done now in the community and put in our requirements that we know from customers and partners so this also finds its place into the standard. So that's it. What I wanted to go through with you. Who is still awake? Okay. So opening up to questions. Yes. What do you think is backup and restore away on the timeline like a year, half year? Backup and restore? You mentioned it initially but you didn't have a project on it. So I think backup and restore is something we need to, for us it's a no-brainer. We have it today. From a Cloud Foundry perspective, I'm not sure if we are providing anything there. I discussed it briefly in the service fabric so it's available right now. So there are basic requirements we tackle with the service topic to provide an easy way to do backup and restore. For OpenStack, it's there. For AWS, it's on its way. I can't really tell you now for AWS when it will be there. But I mean... It's being worked on. What I wanted to bring across here is actually we are already working on this at SAP. So for most of the things I have shown you here, we already have a solution built into our products. So what we try to do is to put these efforts into the community back so that something can be reused. And for the service topic, there is now already something for OpenStack. Any other questions? For life cycle management of applications, right? So the idea is that you package your applications in a way where you say, okay, if you use the standards for life cycle management, you can take the application and deploy it on any other certified Cloud Foundry installation. Of course, it will then depend, right? So if you are writing an application which uses proprietary technology, of course, you can't move it, right? Because the proprietary technology is somewhere else. I don't know how this will be tackled in this standard. But the goal is really... I mean, from a user perspective, to know, okay, if you put the stamp here, life cycle management according to Cloud Foundry and the application, it will then depend on the application. Life cycle management, according to Cloud Foundry's standard XYZ, you can move it to another platform. Maybe there will be some rules that you should not use any proprietary technology underneath. Because then it's, yeah, it's not possible. It's mainly around everything around the life cycle management and to package things. Yes? On a daily basis, on HANA, the life cycle is... Poo, good question. And come to the booth and I will find the right person for you. Yeah, because, I mean, so who of you knows HANA? Can you raise your hands? I'm a very active person. Okay, who of you does not know HANA? Yeah, don't be shy, yeah. So HANA is a memory database it's an appliance, so it's a big machine with certain capabilities to run in a database in memory. And, I mean, just that setup is already a platform on its own. And this whole platform is also available on our pass offering. So whether or not IPsec is already used in HANA, it's something I can find out for you. Just come by the booth and I will get the right person or just call a colleague. Yeah, but as I said, I mean, from the beginning what we really need to cover is everything around requirements about security and clouds. And, as you know, also European companies are very conservative with regards to clouds. So that's why also security here plays even a bigger role. The classic sub, are three installations at the customer's side? No, so it's a platform as a service offering. I don't want to bore you now with product specific stuff. So the HANA Cloud Platform is really a pass offering and what we are using it for is really as a possibility to extend other solutions. It could be an SAP R3 system which is running somewhere on premise. It could be a database from another vendor where you want to expose certain data into the cloud. But it's not substituting on premise system. It's rather a platform for us to integrate with other systems, to extend other systems or to build new applications on top of it. It's not to substitute others because SAP didn't have a platform as a service offering before. Further questions? Okay. With that said, thanks and don't panic. But there is one thing I forgot to tell you because I told you you would actually learn the formula for life, the universe and everything. So, okay. So it's easy. Just come and join our SAP booth. It's booth number four and you can find out two together with the SAP colleagues. So the answer is again 42. And if you want to get in contact with me this is my information. You can find me on Twitter or at Rui.noguera.sap.com. That's it. Thanks a lot for listening.