 My name is Christian Brinker and I'm from Ivoila. We are a cloud company helping other companies to commit to the cloud to transform the IT technologies. And by that, I'm here as a software developer at Ivoila. We developed several service brokers and made an open source framework out of it and now we're helping to others adopt to getting to start developing their own service brokers. One question ahead, has someone in here already implemented service brokers for Cloud Foundry already? One hand up, okay. Okay, then get to started. What is the task here about? And one step ahead, we wanted also as the last session in here wanted to do a two hours deep dive into the code, helping you to program a service broker on your own. Unfortunately, we got 30 minutes so we have to speed up a little bit. Okay, what's the task? You have your Cloud Foundry, you have your application which you want to run there but you need additional services like databases or something or message queues or whatever. So you have to do have there some service at some service source. One possibility maybe is you have a web app and you want to go to your MySQL server which is hosted on your iOS stack like OpenStack or something. But how do you get there? How do you get this one running fast, easy as your apps which you can deploy fast with your CFPush and you have it. So the trick in Cloud Foundry is you have some thing called service broker. Your Cloud Foundry re-installation has the, using the Cloud Controller to manage all the things. Know someone who can get you some service and this is called the service broker which knows on some backend to get a service. And so if you get there, you say, hey, Cloud Foundry, get me some service. You say, hey, service broker, get me the service and the service is deployed and the service broker tells the Cloud Controller, hey, that's the way you can connect your apps to and then gets the credentials to your application which is then able to access the service. What types of service are there? You have managed service by service broker on the backend. You can also use a user provider service so your app can be said, hey, it's a service for your other apps but that's not part of the thing because you do not need a service broker for it of the session. You have bindable services which can be connected to your apps. You have non-bindable services which are not connected to your app but you can connect to themselves to it. You have route services which are intercepting the messages sent to your apps and get back and the syslog drain services which can collect the syslog of your applications. For the route service, there's another talk in this conference I've seen in the program so we don't match it here. So let's look a little bit deeper. If you have your Cloud Foundry installation, you can create a service broker by telling the Cloud Controller how to access the service broker where it finds. Then the Cloud Controller fetches a catalog of services presented by the service broker and if you call the marketplace in Cloud Foundry, you get this information from here. Afterwards, if you say, hey, I want some instance of this service. The Cloud Controller says the service broker provision me one instance. For example, the MySQL database is created and then afterwards, if the service, if you want to bind your application against the Cloud Tone Pro, against the service instance, it creates a binding and that means here our credentials get it back to the application. The same, deleting the binding or deleting the instance removes the instance. So we have to do some REST calls, REST interface implementation, many big stuff of course, having to include the complete thing but we do not have to re-implement all the things because we've made a framework out of it. So if you build this up a service broker, you can get easily all the application, those things together. We made it open source, available on GitHub. The service brokers are deployed as made as Spring Boot applications. If you stay at the last session here, you've heard a little bit about Spring Boot and building Spring Boot applications which makes things easy, also including here Spring Cloud as with Spring Cloud configuration and making build management with Maven and we are happy for your contribution to it. If you want to add code, new service brokers, scripts for deployment of something, adding at the documentation, we're happy for your aid. And let's get a little bit look, a deeper look into it. If you have your service broker, you have to deal with something with the catalogs. You have to tell the cloud controller how to access services, which services are there, what is interesting at that for the marketplace. That's done by the catalog controller. You have service instance controller doing the things about the instance creation using deployment service and here some kind of platform service which uses the deployment on some platform or something. For example, if you want to do our example from before, with a MySQL database deployed to your open stack, we have to create some custom code for deploying MySQL and some code for doing it on open stack. If you see here, the red things and the blue things, the blue things are covered by our framework, the light red things are also implemented, also open source, maybe used by you, but maybe exchanged, we see that later on and the red ones are the CAS service specific code. So we can reduce when developing a new service broker, we can reduce the amount of code which we have to do to the one specific to our service. So instead of really implementing all of the code used to handle with cloud foundry and so on, we can shift that away and say, we only want to use the code, make the new code to adopt to the new service, deploy for the new service broker, so we have only to deal with MySQL, not with cloud foundry. Also, when you have for the binding, we have the same thing here with some custom code for the binding service and the rest is done away. Because we developed it as microservices, no state is in the application, so we have some persistent service which persists the state to some database. For example, here Redis, so how to define the services for making that more easily, we added some kind of definition YAML file, the service definition YAML file, where you can define the service which is presented in the catalog and the marketplace to the customer of the cloud foundry side. So for example, you can define an ID for the service, a name for the service, a description shown in the marketplace and if it's bindable or not, and several service plans for each of the services. We also provide some metadata field which can be accessed, and so you can easily add and remove new services based on that. For example, here in the metadata part, you can define templates for use by heat deployment of new virtual machines on OpenStack and exchange the templates easily by changing the property and re-deploying the application or something. Also, the configuration of the application can be made because it's spring boot very easily by your application YAML file. You can define several profiles for different kinds of deployments. You can edit, for example, the persistence part of something easily and what the best thing is, it's spring boot. It's can use spring cloud, so you can also shift this to your spring cloud config server getting the config information from your remote side like a git repository or something. So, that's part of the talk. Let's go to the code, which is more interesting, maybe. So, I don't think you can read it, so I make it a little bit more bigger. Is it possible for you to read that up there? Good. We, because implementing how to get into the structure is a little bit maybe not so easy. We made an example project on a git repository, an example service broker. If you look at it, we have here some small code, we have only there, and a POM file. If you look at the POM file we see, there's not much in it because we have a predefined parent and we can add it only, core dependencies for the service broker, which is the blue part from our graphic we've seen, we have added the Docker usage, the OpenStack usage and the Redis service. So, this is the light red part from our graphic. So, the blue part is there, the light red parts are there, so we only need some service specific code. Let's look. We have here an application. Okay, Spring Boot application, nothing interesting in here. Hmm. We have a service, an example service binding service. This is the interesting part because for binding a service, we only need creating credentials here. So, what is put back to the user, like a URI with credentials in it and how do we delete a binding so we have only to define that and also custom property handling like service specific property handling getting down from a config files to the code. That's all you need for a slide startup. Additionally, you need some heat template to deployment. If we look yet to the more specific part, like, hmm, let's do a service broker in CouchCB. We have to look, we have to rename some things from the code, we made a, because we have a short time, we made a list on it, put it on our repository for the coding session. We've shown the, I will show the link later on and what have you got there? Hey, we designed, said, ah, credentials. What do we do? We have admin users for this database. For easy use here in this, for the slides we use the demonstration, we use the service instance ID and we want to do a database added in the Cloud Foundry installation and the CouchCB installation which is named after the binding ID and also user with password for it. And afterwards we get back to the user for the app to Cloud Foundry, a URI which has user password and the host IP and the host port of the deployed CloudCB instance. If we delete a binding, we have the same credentials and let's look what code we have to add. So if you go to the final step here, you see the projects we added with our maven dependencies. So we added the core function of the persistence and some model specific parts from the core but the interesting part is what do we have to add? When we start, we add only some CouchCB framework to access the CouchCB server for administrative usage. We added some boilerplate code for usage of the user and database management of the CouchCB which is not part of the framework for adding users, adding administrative usage, adding roles and such things. But that's service-specific code. No code used for the deployment with CloudFoundry. So what do we added for the service brokers part? We said, oh, there's a problem with CouchCB and using the ID. So we added some lower case letters but that's service-specific. We said that we wanted to use the code from our CouchCB framework to add the user if we bind it to the service, create a database, add the user to the database back to credentials. And if you go wider, we can delete the user from the database, maybe delete the database too but that's all. The rest is done by the framework. What do we have to add then to get the new service broker? We have to add deployment scripts like a heat template for deploying to heat. So it's like here, some script part, deploying all the things you need to deploy a new CouchCB instance to OpenStack or the Docker commands to run it on there. You will get information here from our service broker property files in here shifted to us. We can also manipulate them using the custom properties handler. And if we look at the application YAML file, we see some general purpose usage and here getting the scripts down to the heat template from some Git repository also here on our repository brought to you and also some service specific configuration like the port we want to get to the CouchCB instance. But that's it. No more code is needed to get a new CouchCB instance if you want one. You get new users added, new databases added if you get your service. If you say to the cloud from the instance, get me some new instance, bind me my app to that, your app gets its own database, it gets its own user on it and you can access the data there. And if you look how easy it is, so here you see we defined, we get a new service instance of CouchCB with a size, a t-shirt size plan M and we call it test and it's created. If we get a new CMD open for looking in the meantime at the marketplace, we see here we have CouchCB addressed with plans S and M. And if you look at our code, at our service definition YAML, we see here, we defined CouchCBS here with the CouchCBS service with plan name S with some text, some definitions. So we wanted to create it and to deploy it to Docker and if you look here down to OpenStack, we said to size M, we said, which we used at the example right away, we said we want to use it with OpenStack. So we deployed at the moment, we typed in the create service, a new instance to OpenStack, which whereas installed the CouchCB installation and we have to wait until the application instance goes up. There is in the, it's an asynchronous service we are binding here for someone who is also getting a little bit into the service broker API, which means the service broker starts the deployment and waits for it to end. So it's going to look after the installation installed instance if the service is already there and afterwards telling the CloudFoundry if it's, if the service is up, if you look back here, we can see, see if services, our started services and yeah, we see, didn't get up the CfPush for I forgot to push the application. Ah, that's a problem with live coding sessions. Excuse myself. So what's also there, we have the service brokers are applications with Spring Boot application so we can easily deploy them as applications to the CloudFoundry installation. So I've pushed at the moment my installation up there and if we look back at the code, we see there's a manifest file in there saying under which name it's deployed up above with the which Spring profile so we can switch the configuration from deployment to deployment. So if we, if you want to join the coding you can use the code we presented here on the Cf, on our CfSummit repository at the slash voila, GitHub organization. You can also get our other service brokers like MongoDB, Postgres, Redis, RevitonQ or something. Also with the core parts, the deployment repository parts and so on. So which additional features have we back there? We have remote control of the HA proxy for getting you access to your databases out of the CloudFoundry installation with a little bit of an extra project which is called HAH proxy backend and HAH proxy agent. We have implemented the logic for the routing services. We have additional features for deploying also database clusters, not only one single instance but deploying for example several fully grown MongoDB cluster with query servers with replica sets and so on. With existing service brokers, log search, elastic search, MongoDB, MariaDB, Postgres, and so on. Cloud configuration, service discovery from the Spring cloud, Spring clouds things. And I think we are back here so we can create this service instance. So I would say we start with a question round and wait for the service to come up so I can present to you the installed DB and interface. Are there any questions left? For sure, if you see here, green button, if you're interested in service broker development you can come up to me at the whole conference, contact data, if you don't find me, my colleague Alex is here. He knows where I am at the moment of each time of the conference. Afterwards you can email me, contact us on GitHub. So free for your questions. Unfortunately, like I said, we had only 30 minutes and wanted to do a deep dive into the code and had to change because we were sad that you have only 30 minutes. Yes, the framework is in production use. So it's major, the versioning was because of we changing the structure of the open source GitHub. And because we changed also the Maven dependencies and redesigned which parts are core functionalities and which are not, the open source version is actually in 0.1 RC because we want to get ready that it's stable. So it's only because we've done the changes two weeks ago and aren't finished yet because we do it not full time programming but in part time of our working time at the company. So it's only, that's the only reason it's 0.1. Because the new structure you've seen on the graphics is a little bit different and we want to get that straight. We are here for the one to zero version of the new structure in about two weeks or so. But a good point. Yes, you have, that depends. So you have to see the service broker itself. It's a Spring Boot application. You can deploy it to where you want also to Cloud Foundry. The service you want to implement, it depends. Maybe your service is not an instance itself. So it's maybe some kind of abstract thing. Like you have a Jenkins server and you want a service instance is like a new project on the Jenkins server and binding a service means that it's somehow added to the Jenkins. So you need to change some things of the connection. You see here, we've made this structure for that purpose. So you can here make some logic, deploying, accessing the existing Jenkins server for example and here adding a new platform service which orchestrate these things. And here you're doing things like adding new stages or something or adding this as a service in the Jenkins pipeline or whatever you want. So it's made, so the blue parts are getting the concepts of the Cloud Foundry side of the service broker API and the red ones are for change, which can be changed. We only developed OpenStack, Docker and Redis for the moment, but that's not the thing we want to go to. It's only part of the work done. So, and happy for contributions, forking new projects, adding new projects, add the CF service broker, GitHub repository, we want to try to get something like an inventory of existing projects. So if you have your own one by forking our code, tell us, we put the link on it. And so that's one of the main reason we changed the structure. You have not all code on one repository, but divided. So we have for each of the custom service brokers, for example, one single repository with a new setup. So I think we waited long enough to see CF bind service. So we have no app here in the space, so I used the service broker itself and bind it to our test database. If we go to the, there it is, our new database. And if you see here, it's the binding ID of the service instance binding. And if you go to the users list, we see the new user with the same ID. Any questions? Programming this, I started last Friday. So you see it's not much easy, not much time to you need to implement a new service broker with this. Unfortunately, it's a Spring Boot application which uses Java, so it's a Java framework. But you can, looking at the code, it's open source, so you can easily adapt the code to other languages, for example. Yeah, yeah, very good question. If we look back here, enjoy this one, very easy. Or maybe that's more interesting. You have several different API endpoints to implement with several parameters which can be added exchange for the different kinds of services. So it easily gets a little bit frustrating to get all the things into it. And it is a little bit problematic to adapt the code from one service broker to another if it's too hardly coupled to the original code. So if you want to develop several service brokers, you have to get an interface to it. Because the API to the CloudFronry system isn't changing. If it's a service broker for CouchDB, if it's a service broker for some other custom service like Postgres, Quial, or whatever. So only the information in the parameters change and maybe a list of custom parameters is added to the meter data of the JSON file sent from CloudFronry to you. And that's the part. So another challenge was to get here things done like if you wanted to have several service brokers at the same time, which are also failbacks of themselves. So you have to maintenance a state in some external database, but remain here. And if it comes into challenge with the Ethyn Chronos service instances, so you have deploy service, you have only not 60 seconds but longer time and you want to follow up the maintenance, the progress, you have to get into a chief that it's made change over time so you can have the problems of the job is created, the service broker crashes, another service broker comes up and has to get the same status up and so on. So it's the maintenance cycles you have in production systems. And also to adapt from different deployment systems to one single point of code. So you don't depend on where gets the service to at this part of the code, but only it's there and this handles the rest. Other questions? Okay, or okay, then thank you. If you want to contact us, here are the informations or see you on the rest of the summit.