 Welcome to OSB Local, we will be talking about service brokers on your machine. My name is Christian Brinker, I'm a software developer at Ivolá and I talk about a problem I faced a lot of times during developing of software. What is the problem we want to solve with this? I'm a dev and unfortunately sometimes I'm also consulting somewhere and in between I want to develop something in the train maybe on the drive to the customer and to test something and unfortunately I like Cloud Foundry and the Cloud Foundry experience but at some times you don't have internet access, you cannot access your Cloud Foundry maybe, you may be remote or in a hotel room with a bad Wi-Fi and you want to test something and then you don't have a Cloud Foundry. So several people came up with this idea, hey, why don't you have a local Cloud Foundry on your local computer which is CF Local, CF Dev, different types of ideas. By the one you have Docker containers, by the other hand you have a fully fledged VM in the hyperkit running on your local machine and you have all the things stuffed in there. So this is cool, now you have a local Cloud Foundry, okay, CF Dev is not that un-consuming of hardware resources in your laptop so with this old guy here it's a little bit of frustrating sometimes but you have it. You can test things, you can experiment and so on. So you have this idea of a Cloud is more or less equal to this local Cloud thing. But let's face another problem, I'm deaf and I have my local Cloud and now my friend here comes and says, yeah, I have a cool idea. Let's make Mongo great again and use it in our project. Now get sad because why? My local Cloud PCF Dev, CF Dev made only have my SQL in it but no Mongo. So I have the problem to get a local MongoDB stuck in there somehow. So I'm really, okay, where can I get a MongoDB? Maybe I can take a Docker container, spawn it, wire it somehow in the network of the CF Dev and okay or I have to look for some service broker and look how could I ship this thingy and I'm really getting a little bit frustrated. So the cool idea is I want to have local Cloud with my MongoDB service in the marketplace. That would be awesome and that's what makes me happy so I can develop with it. But not only with MongoDB with every service broker around, I want to start with. So what is the idea? I have my local CF Dev with Cloud Foundry, with Bosch Director, with my SQL. I didn't use CF local because most service brokers need a Bosch Director to deploy something which we don't have in CF local. Then I want to have a service broker, some more thing and I want to have a CLI plug in for my Cloud Foundry CLI to start that thing up, to make the service broker available in my CF Dev in an easy way. I don't have to think much about it. I only start working and then I get my marketplace things there. So this is then OSB local as a concept. So what we have to achieve? First of all, you have to have some kind of rendering mechanism for the service brokers. Why that? If you look at service brokers, they are a little bit different. They all have to be a little bit started differently, how they work, how they will be shipped, how they will be deployed. There are tiles, there are no tiles. They are deployed as VMs, as a cloud native application inside Cloud Foundry. It's all a little bit different. If you look at different kinds of service brokers out there. So you have to have a standardized rendering system for the service brokers. Then you have to load them via CLI into CF Dev so you can use them in the marketplace, create service instances, create service keys maybe for local testing outside of the CF Dev. So you can use these service instances with your IDE. So you can directly use them in my IntelliJ, starting some of my stuff there locally and connect to that database also. So because I have it there, it's available. And then I can also push to CF Dev my app. And the best thing with that is, if I want to restart my tests, I delete that service instance, create a new one and start over. So if you look at Docker containers, you have that problem maybe that the Docker container may be stopped and started and maybe lose things. And here you have a proper lifecycle management through the service broker maybe. And we also have the possibility to add amounts of saving to the local disk. So you can restart things and so on. So what we're doing with the CLI, I want to start over with my service broker. So first of all, I have to have a vendor version of my service broker, which has a direct way to interact. So my CLI is needing some container for my service broker. I don't know what it is. It could be something different, but I have a tar file, a tar ball with a deploy and a remove script, which can be run on my machine locally to start up that service broker to deploy it somehow and to remove it. And I have some binaries in there, some push releases maybe, some config files maybe. I don't know because the deploy file, I want to start with my CLI student the job. And what is done, the deploy script is called from the CLI to, with giving me a host them, it wants to register later on the service broker. And the username of the password, it wants to use for that. And the other thing is later on, it wants to remove that service broker. That's it. So for example, with our MongoDB, I have a deploy script, my remove script. I have a JAR file, which is the service broker. I have a push release, which creates MongoDB VM inside of the hyper kit maybe. I have some config files I want to use for the deployment here. And I deployed with my service broker, admin, admin. And later on, I remove it that way. So what are the benefits? What did I achieve against getting Docker? First of all, I have the same deployment methods used alike in production. If I go later on to Cloud Foundry, my test experience on my local machine is the same. So I've completely the same thing, the same way to use the services. I don't have to use cups on my local machine to get that Docker stuff used for my CFDF, I do not have to tackle with my networking or my local machine to the hyper kit, where I have to tackle these different things with my Docker. The service brokers are maybe the same things I use also in the production environment, because they only use a small plan instead of big cluster. But it's more or less could be the same service broker with a different plan, which is used for local tests, which I use for testing also in the test stage in my production environment. I can use the CLI plug-in for scripting in difference to that. I can have Docker files, which I mostly have to get from somewhere. So I get some from Docker Hub, some MongoDB, Docker file, and then I say, cool, and yeah, this doesn't work that way I thought so. Then this, and the MongoDB is completely different configurator than in production. Then maybe, but there is a Docker file for everything on the web. So it's a bit of a things for that. But if I look at the two operations with my databases, with the Docker file, I have to do all that things by hand. I have to delete my Docker file, I have to restart it. I have to look at how it is started up. Do I have to introduce some advanced configuration stuff so it's comparable to the things I do in production, where I have here a database lifecycle management through the CFCLI, because it's a service broker. And I have a service key management which I can also use to make it differently available. So let's see what it does, how it works. Okay, wrong package I see, so, where we are. I have here my service broker repository folder, whereas I have my service broker in there. So I have here the files I talked about, the deploy file, the MongoDB jar, and here I have my packaged table, which I now want to upload to my Cloud for Android. So if I go back and I, CF, CF, OSB, got it wrong, CF, OSB, CF, OSB, add. So what I want to do is, I want to, this is one step, I forgot. Live demos, summit, it should be local. MongoDB service broker, create and serve. Forgot to start my web server, now we can do that here. Starting a web server for providing the tar file for me. Now if we go back, if we go back, CF, OSB, add. Now we retreat from our local web server, the tar file. Adding the things here, creating new space for my service brokers, uploading things, and look in and now marketplace. Nope. What did I do? Did I get it wrong? CDLS, I see it. MongoDB, Mongo, TGZ, to kill that one, excuse me. And now it go. Now we see it. Why don't you want to talk with me? Yeah, I can do that. Ah, you're right. You can totally right. I knew, I did. What changes to Mongo? What changes here? What is, what? You use Mongo.tgz. Ah, now it, yeah, now it loads Antares, uploads. This is the power of Perry. Yeah, it's perfect. Takes some seconds, I know, because it has to upload that to the hyperkit VM of the Bosch director and spawn a VM in there and installing MongoDB there. So because it's a pre-provisioned MongoDB servers. In the meantime, any questions until now? I know it's a little bit flaky with a demo, hands-on demo. What I created is, I started a service where the files I described beforehand into the tab all, upload, made it available with the HTTP process. Then I said I wanted to edit as a new service to my CFDef and make things available there. In the meantime, we wait. Let's talk about where we want to go with that. In the long run, we want to go to CF local because this is a little bit more less aggressive in the resources of your local machine, but the drawback is you have no Bosch director with that, which most service brokers need. So we have to circumvent that. We actually have seen, I used a web server for that because the initial CLI tool only use web address at the moment. I want to change that you can change between local file system and using the web address. You've seen the debug log is not that optimized. So we need a bit more for there and only at the moment because of CFDef and so on, we only support macOS. With CF local, you have also other distributions like Windows working. And so this would also improve the footprint on the local machine. Our documentation could be better and we want to have a standalone mode without CFDef or CF local so you can also use this for providing your database locally without doing all of the other stuff. So you can only for your IDE spawn up the MongoDB, then remove it and so on, maybe with Eden, CLI and so on. So you can directly interact with that. Let's switch back. Oh, I know. No, let's have a look. What's going on? Ah, no, it's there. What's in between? So if I now want to test something, an app, so I have a script for spawning up a new space, adding some information about that in manifest and then pushing our music spring app to Cloud Foundry using a new service instance I created. I can easily do things like that. So where is it? So if I have this thing here, so he says there's no test instance, so I create, so I go to Marketplace, CF create always be MongoDBXS called test. Ah, you're right. What is my typo day? It's already there. It doesn't do what the wrong one. Clean up, know that I didn't want, test, test. Somewhere there are too much presentations. There's nothing more in my history than test, test, test. It was space service, service plan, service instance app, app path. So it is, test as age, the greatest was test, test and music, service, did I miss something? Space? Ah, yeah. So one more test. XS, did I get it wrong? So you have two tests in a minute. No, I think I know what's the problem. Oh, yeah, location. Looks better. Nobody can accuse you for not being live? No. This is not a fake demo, I guess. Should we take some questions? Yeah, we should do. Do we have some questions to that? And now it looks a little bit freaky at the moment because of the demo. And I tried to script things and then forgot to. So I'll ask, you said you want to add it to CF Dev? Or something like this? No, at the moment it works with CF Dev. So if you have to have CF Dev started at your local machine, I did that beforehand. And here you see the code from the music app. So if you look at browser, I don't think that's the right one. So this is the spring music app using the MongoDB service. And so what we were talking about, what I meant was we were using CF Dev. So I've run CF Dev, started during the keynote, started up my CF Dev, and use this now here. And by the CF Dev has a very big footprint on your machine. If you look at the, it takes about more or less of this old laptop here, the full memory, which is not cool if you want to run an IDE next to it. For that, CF Local, which uses Docker containers, it's a little bit less strong from the footprint. And because it doesn't utilize, it makes about the user experience, but not about creating a complete Cloud Foundry next to it. It would be much better for the user, for the developer. So we want to go there. But CF Local, because it's a Cloud Foundry deployment, doesn't have a Bosch directory, which most of the service brokers need. So what we have to do then is deploy a Bosch directory for the CF Local to work with it. And by that, we have to look when start making the CF OSB ad that he looks, is there a CF Dev or CF Local, and then starting the things for it. So this is work to do. So you can use less footprint. And also, we have to come up with a trick if there's nothing of both. So you can use it in standalone mode. Coming from someone that is running Cloud Foundry on Kubernetes, the missing Bosch directory in CF Local is kind of a feature for us. Because so many things currently in Cloud Foundry rely on Bosch being there. And, well, not even sure how this is going to be solved in the future. The problem is most of the service brokers at the moment do. So if you want to use arbitrary service brokers with that, you have to have a Bosch directory for them prepared so they can utilize that. You're right. If you want to get along without a Bosch directory in the long run, and you want to use Kubernetes for your data services, you don't want to have that. So we may add some information in the configuration of the service broker tab all to show any of the Bosch directory I don't need it. So you can deploy them with less footprint. This could be a possible solution. Maybe one very technical one. You were always using SH, so the born shell when you ran your scripts. Is this explicitly to avoid people running into bash and something like that, or reinstall and deploy? The plurse edge is at the moment it was only, it is a little bit of enforced. But I'm not sure if that is a good thing. It's an early stage of the project. So it was for the easy access, because an SH is easy to write. For the long run, we have to come up with a better trick for that. I feel like a little CLI. Yeah. I didn't work with some of the technologies you showed in quite a while, but the last time I used them, it was very, very flaky on the local machine. The CFDF. The CFDF as well as Bosch Lite and everything. Yeah, you're right. And there are quite a few differences between depth and production once you use them, because you have completely different setup locally than in production. So would you say that this small gain of depth brought parity you gain by the setup is really worth the effort compared to running those services in Docker and just bind them to Docker? The problem with the Docker thing is you have when using Service Broker, you have a distinct configuration of your service. So it's not about the cluster or not a cluster for most services, but also which are the predefined type character sets and so on in the configuration, how it's preparations for the wrapper set configuration and so on for bigger clusters. You have also in the smaller depth versions of the service brokers often. And if you look at the Docker versions you find on Docker Hub, for example, they're completely different. So if you have a Service Broker provider, which has also a Docker file, which would be completely same configured, that would be you could easily use that Docker file. But often you don't have that. So you want to have a service broker configuration like that on your local machine. Very last question. I assume this only works with stateless service brokers, right? Once they need any backing services, this might get a little chicken-ack problem. Actually, this Service Broker has a back end. Which is Mongora. Yeah, which is spanning up on its own virtual machine, which is deployed to his running on a virtual machine deployed by the Bosch director. So if you look here, if you look down there, you have a Service MongoDB VM, which is having the Service Broker. And there he has a local file system. And also there's running a local MongoDB for the back end of that thing. So it doesn't have to have more than one release. Thank you, Christian.