 Okay, welcome everybody. Christian and I are going to talk about what we call the software as a service broker. And at the start we want to talk about the Cloud Foundry marketplace. Currently, if you look in your marketplace, there's typically around 9 to 15 data services present in many cases less. But Cloud Foundry is about getting the best developer experience, so all these developers creating new microservices. And often they don't know that somebody else already created microservices, they're currently working on. So they do this over and over, creating redundant microservices. So we thought we could transform this marketplace to something like a SOC exchange where all these microservices could reduce and you couldn't get rid of a services recovery. So you can improve the developer experience again because you don't have to repeat the work somebody else already did. So last year in Basel at the CF Summit Europe, we created this software as a service broker as part of the hackathon. Three people of our company, us two, Christian Müller and Konstantin Kies from Volkswagen Financial Services. And we won. What's the idea behind this? What did we do? Normally you could say access to the marketplace, for that we have the service brokers. But if you look in big companies like for example Volkswagen, you often have this problem that you have a lot of developers not coming from cloud-native development, not coming from microservices. So they're struggling with getting their new development things to be microservices. They're not cloud-ready software to be available. And so there's a lot of effort in transforming the IT inside of these big enterprise companies. And so they bring up their cloud, they bring up their apps to that platform. And often they have these regulations at the start where they have to automate things. And not for all the things they need, there's a service broker. And making a service broker takes time. And it has to be adjusted, there has to be done stuff in the later on, it has to be maintained and you have to know about the open service broker API. So this is another type of knowledge you have to have. And if you look at some service broker and their life cycle, you see that it's not that easily done. And our idea was to make it easier to get these services they do first in the marketplace to be available. Beforehand you have to have for each of the smaller things you have to adjust to be their service broker and distinct one for each service. Because you do not know if this thing, this little microservice you do, is something other people need. But you have to make it transparent in this big company because you do not know the other developers, the other developer teams, because you do not know what they're doing. But maybe you have to shed interest. So you need this workflow that you have to share with the others. And if you look at service broker, what is it doing? You're in developer. You're developing an app and you're trying to make it available in the marketplace. So you try to use a service. What you do is you use your CLI, for example, connect to the cloud controller, and look in the marketplace what they are, ask for some service, create a service instance. Then the cloud controller goes to this awesome thing called service broker and asks, can you do that for me? I don't know what it is. Do it for me. I need some service instance for some guy. And then it creates the service broker knows how to create the service. So it's kind of an adapter to the domain knowledge of that service. And you get the service instance back and get credentials, maybe, if you have a bindable service for your application. So you get credentials inserted in your environment of your application container. And then your application can use these credentials to access the service. But what does that mean if you have two applications in your cloud foundry which have to be connected? How can you do that? And our idea was then to create a service broker for that, where you can register other applications too. Normally, you have to have domain knowledge for that, but we do not know in our idea what these other applications are. So we have no domain knowledge. We only know that we want to have this application in the marketplace. So what was our first idea we did was to offer some service in the marketplace, which if you create a service instance of it, you get the access to the service marketplace. So creating the service instance means to create the representation of your application in the marketplace. So you book it in your application space of the application you want to offer in the marketplace, and give there in some additional information about the service name, which should be in the service marketplace, some name of the service plans you want to offer, things like descriptions and some other little custom properties you have to add. And afterwards, the cloud provider can update the service broker. And this has to be done because there is no refetch point for the cloud controller to get to know that there is a change in the service catalog of service broker at the moment. And this is a little bit of a lack, I think, in the open service broker API. And then the callback is then that the platform provider can update the service broker's catalog and can then enable which persons should be able to see the new services provided now by our service broker. So the new instance we created is now part of that offering of our service broker. And you can use the default changes of making the service accessible only to a few organizations in your cloud foundry deployment or all. And afterwards, you have this new representation in the marketplace, the new service, the new service plans, and each other of the organization users you can see that can also create a service instance of it, which means that they create the connection to your service, which is only a representation at the moment. And if you then bind your application to the, you want to provide to your service instance in that space where this provider is deployed at the moment, the application route is now added inside of that service, in the service offering. And in the draft we did in the hackathon, we also provided some basic shared credentials. So all users had the same credentials to connect, so it was only like a gatekeeper. So only knowing the domain address would not make it able to address it directly. And because we did it in one day. And binding then the new app, the created service instance in the consumer space meant to get this application route of the provided app inside of your environment with the username and the password. So if you look at the workflow of your usage, you see the first thing you do when you want to provide an application if you do it with your service, you create a service broker, which we did with our service broker, and then it's in the marketplace. The new step here is that you have this updatable workflow if there's a new offering. Then creating after you create a service, a new one. And deleting the service means removing your app from the marketplace after all. And binding service is what I stated earlier. Afterwards, after the hackathon, we talked about it a lot. We had other thoughts in mind, we discussed it, and we've seen that this simple approach is not the end of that story because there are several different problems. First of all, a service broker is some crucial thing because it has some very... The open service broker API is a very good concept of handling services. That's the reason other platforms like Kubernetes now adopted it because it is able to provide you some kind of adapter to that service domain knowledge. And when you look at service bindings, this is even more crucial. But I will state other problems before and now. First problem we see is the service usage. You have this app. This is a microservice. It's brand new, it is added to the marketplace, and it's only something in your company is available. But the other users of the marketplace don't know how to use that API because it's something that team there did. You now have a transparent in the company that there is something, and you have a little bit description of the marketplace, but how to use it now? So the API definition, the documentation is needed for the usage. So things like enforcing a documentation URI on service registration is something which has to be thought about. So maybe when you create the offering service instance for your application you want to offer, you have to have a field which is not optional but required to place a documentation URI available for the users of Cloud Foundry. So they can get from the description in the marketplace to that link and see the documentation how to use that service if they bind one instance before they buy it because through one benefit of this approach we used is that if you have some kind of service mechanism for billing your service instances in the marketplace you can build both the offering service instance as the consuming service instance, both differently. And one other thing which is very important for that thing here is if you have a REST API, think about Haters because Haters brings you the benefit of being able to go through that API, explore it and know how to use it and that's a real benefit in this thing. But we know enforcing documentation does not mean that you have a good documentation and that it is enough. It's more like a thing about you have to have a documentation thing here we propose. The next thing is the app binding. I talked about it a little bit. What does it mean? If you look at actual services like MySQL you know what means to create a service instance for example in a shared MySQL cluster creating a database. Creating bindings means creating users for that database in that cluster. But if you have an app, a microservice, which is not something standardized not well known, what does it mean to create a user or credentials for it? So this is some kind of special domain knowledge of that service and our service broker cannot know about that. So we have only two solutions to that. First of all there is a possibility to have some standardized binding API in that application available for the service broker which would mean we reimplemented partly the open service broker API. So if you come to that place that you need that think about making a service broker much more easier maybe. The other solution is to have some central SSL inside of your cloud found redeployment. If you create a service instance means that you create which for your offering you create an information for the SSL which grants have to be stated to users which have to be able to use that. And the other thing is that if you create a binding you create a user in that SSL where you can add the grants or you have an existing user and add these grants to it. This can be done by our service broker because this SSL is something you can standardize. You can have a standardized way to interact only the name of the grants and the list on which grants are added is new. And then the application has only to have the knowledge about how to use the standardized centralized SSL and this is the same for all applications. So this is something that can be done. When you think of data services you often have a differentiation between shared instances and dedicated instances. Shared meaning you're getting only a database on an existing cluster where the cluster is shared between multiple service instances and a dedicated instance means you're getting a new database cluster every time you are creating a new service instance. But sharing an app comes with new problems. One is you're now having more load on your app which means you need to scale it. You might need to scale it. There are many possibilities. For once our service broker could scale the app or you could use an autoscaler to scale your app but in some instances this is not enough. If you're having a microservice that relies heavily on data services to store some state you now maybe need to scale up the status as well. Get a bigger cluster, get more storage for your database. So here you have a much bigger problem which we are currently not know how to solve. Maybe you can see that then you're managing the service. The team providing the app has to be like a managed service provider so they have to look after that. But there is no general concept for it even if you have service brokers you're here with that problem. Now you shift that problems you normally solve in your platform providing team to the application providers. And with dedicated instances it would mean we deploy a new app to CF. Our service broker needs to CF push an existing application or clone the droplet or clone the container but this comes also with a bunch of problems. Maybe we need to worry about the state of the app so we need also to create new data services. We need to think about backup and restore and what happens if the original app developer deployed an update for this app. These are all things our service broker would need to handle which would basically make it a meter orchestrator so we decided to scrub this idea all together and only go with shared instances. And the last problem is about SLAs. Who owns this service? Who cares about the service? Currently you have an app developer and he's pushing his app and maintaining his app but he's not guaranteeing you an uptime. Not as a service. Maybe he's caring about the uptime for himself but not for everybody else. So who owns the service and who's liable if it goes down and my app goes with it. Who can I contact if I need to support and where can I find any more information about how to use a service and maybe the roadmap of upcoming features or feature requests. We have two solutions for that as well. The first one is the same as for the service usage enforcing the API documentation and enforcing documentation for other services as well and also adding custom property on the service orchestration for the contact to the owner of the service which we can display in the marketplace description. Yeah, the problem as wise would be that each user of some offering in the marketplace which is provided by our service broker would go to the platform team and say hey, your service is not working and then they have to say yeah, but it's not from us. Contact please these people. Yeah, which is really not very necessary if you can make the direct contact and also if you can make the SLA visible to the user hey, it's not that production ready now. That's an important thing to communicate. There is something but we need time to make it production ready or if you're interested you can try it and if you're more into it we can make a service broker out of it. And our code is on GitHub. We hope for contributions from you for bug fixes stocks. We not produced all the features we talked about now because there was this big discussion where we had to look into what is really needed what's the feedback of your community and that could be your best contribution to us. Talk with us, bring in your ideas about it what do you think is worthwhile to follow up what would we skip what's your opinion about it and I would hope for the questions answers to be your first possibility to contribute to us. So that was our talk. If you want to contact us you can reach us here or on the GitHub and now here directly if you want to and we're around until tomorrow. Thank you. Any questions or some things you want to contribute to us say to us. Maybe with the microphone. I was just wondering if Credhub solves the credentials problem you mentioned earlier. No it will not because the problem is we do not know how to create the credentials if you do not know how the application does that. So that's the big problem. We do not know the domain of what is a user what are credentials in the service. If you look at Redis for example we only have that secret. If you look at MySQL we have a more widely more complex system of user and things and if you look with shared and dedicated services some service instance some user of a shared instance means something very different than with a dedicated one. If you have a dedicated cluster for example this could be some administrative user or only some user who connects to some database and so on. So it's cascading there. As a service broker you can manage this because you can specify the special interaction between the user and the service because you have this adaptive logic which we cannot provide because we do not know what is needed. Other questions? Then thank you for your attendance and hopefully we will hear from you soon. Thanks.