 Okay, let's start Welcome to the service brokers one-on-one that extra something The conference is nearly finished now, but we are not finished with our stories. So If you weren't in the getting started track until now We're trying to get you folks with it into new topics and you know not faced Until now or if you're new to look to cloud foundry to get you started with the topics that are interesting And this talk is an introduction to service brokers. So you guys get started with the staff and get to know what a service broker is what it's doing for me and Why should I use that and what's the interest in that topic? So let's start First of all, my name is Christian bringer I'm working with you. Voila we're systems integrator and We are very much into service brokers. So that's why I'm here and I'm also an ambassador So if you're around have questions, we have these Things here these patches you see the Cloud Foundry ambassadors if you have questions to anything about Cloud Foundry reach out to us ask us We are also every at every conference. So you can also see us at the European Summit and we always will have some batch on us. So Feel free to ask us about anything about Cloud Foundry At least we will send you out to the guys who's at the most specific answers because we know that so Service brokers, what's Cloud Foundry about? Cloud Foundry is about shipping your app. So you want to ship your app You see if push it you're fine with it. It's cool. It's running. I don't have to care how it's deployed and and that's cool This is Bob he has shipped his app. He's cool with it and now he he wants to make his app even better But what he gets from Cloud Foundry is he's now a proud and deaf parity Because you can make several spaces push his app to the several spaces and by that a staging concept Which makes this the switch from a development perspective to production really easily? He can scale his app now. Yeah, whoo cool He also has routing. Yeah, he has domains for it. He has Routing over its app. That's all cool. That's the platform. What's the platform about? But what he doesn't have isn't database out of the box and that's not part of Cloud Foundry to have a database for backing up your app and There's where service and service progress comes in. So Cloud Foundry doesn't know how to ship my sequel database or something else But you know what you know is this that marketplace experience you go to see if marketplace you see all that that are the offerings I can I can create some service there. I can make some a switch between plans select one and that's an SSL SLO I get there. So someone is promoting me you get here and in super high Available database service, which might where you can put your loads in it, but that's not Cloud Foundry Cloud Foundry is only providing you with that information What in the background Cloud Foundry is doing is talking with a service program And you even want to have more things for the app. You may want to out of scale your app You want to get your locks somewhere centralized You want to have some changes in firewalls for your application automated You want to have maybe a message queue in front and all that stuff connect to the application at best as environment variables stuffed into your applications runtime so you can easily consume these variables in there as environment variables of your application in your runtime container and Utilize that to talk to you the message queue talk to the database and you don't care where it come from So that's part of the the experience the platform brings to you So what you have there as a concept is Cloud Foundry with its application and you have some servers of some And it's coming from some fantastic services. You don't care where it is For example, it could be and it's only an example Cloud Foundry as you have a web app and you have OpenStack and they're running in MySQL For example So what's the service broker for in that? Um, that's easy if you're a developer you go to your cloud controller and you say create service instance That's the first arrow here Then Cloud Foundry in the in the background caused the service broker. He knows he has told me that plan He he can create me that service In the background, he's deploying that creating something for you making a database. Maybe running some SQL scripts in the background Maybe creating new virtual machines or whatever And then test cloud found the cloud controller. Yeah, I've made that That's there if you want to use it Here the information for your application do it And then the application can directly interact with that service instance So The interaction on the runtime of the application isn't through that service broker. The service broker is some magic Adapter for your cloud foundry platform to get to the services to the customers And it doesn't have to care about the specific domain of that service. It doesn't know what that is doing It's handling its life cycle management Um, why is that possible? It's because of the open service broker API um That's a project Because that concept of having someone doing the stuff to get a service for you It's not only necessary for cloud foundry. It's also necessary for example Kubernetes And that's why the open service broker API First in the past was created for cloud foundry is nowadays Also, therefore kubernetes so you can plug that into kubernetes And then you have the same experience in kubernetes like you have it in cloud foundry And um the spec is out there. It's open. You can contribute to it. You can discuss it raise issues I need that for if you i'm developing a service broker I can say I need that feature in the api spec and it gets done And back to cloud foundry and kubernetes from there because they're implementing That api that's the way cloud foundry talks with the service broker It's open source you um on that uh address um So what is this all about? Um, what type of services could there be? um In the concept of the open service broker api. We are um have different kinds of services first of all we Divide between managed services and user provided service instances managed services. That's easy That's the things you get from the service broker and what's user provided service instances There's that call in cloud foundry cli cf create user provided service and you can put there in some jason What's that about? I have some service instance. It's already there Um, I don't want to make a service broker out for it And but I want to have that feeling of using one service broker So you can put the credentials to that service instance that ip address the username the password in that command as in jason format and then Your bind that service instance to your app Started and it's the same feeling like with the service broker but For that single instance and you have done the the work for the of the service broker by hand in that um The alternative um if you've managed With the service broker um, what are the different kinds of of services you can have for example? You have bindable services and you have non bindable services. Why should I have a differentiation in that? And bindable is you can put that on your application. It's something which is connected to your application which can Where you have to for example want to have credentials to your database inside of your applications runtime But at some points you may not want to have your service may is something more abstract You are on the space level of something. It's not specific for one application, but it's a thing in general For example, that could be some Stuff about you want to have provide your platform customers something like and service offering a support level They can book via the cf marketplace. It's nothing you can add to your databases But it is something which creates some stuff in the background through the service broker Maybe changes something in the account management of your that customer and it's bookable by the marketplace The other things Which you can have specific types of services are route services which are not binded to an application But to a route So you can say all the traffic that it's going through to my application I want first to go through that service instance and that service instances Is Looking at that stuff and deciding if it's going to put that to your service To your application instance or not So for example, it could be some Some security stuff scanning if there is some injection in the traffic Or it could be some kind of Load limiting stuff so you can Look into it and if it's too much of Communication going through to your application it cuts something off. It's all the stuff you want maybe have in that thing It's more like or less Men in the middle attack for your service. So your service is scanning that that that communication without your app knowing The syslog drain Service is the thing you can you have, you know cf logs Maybe you can get your logs from your application through your cfc li And but you also can say all the logs my application is doing Please send that to that address and that's the logs syslog drain services are for And the third Big group is volume services and special ones. These are I want to have an application and that container should have a mounted volume Inside it's an Not a persistent disk. Maybe you want to have there or a bigger disk and you want to use that It's a special very special case um In my opinion, uh, if you want to use it try don't to Because what you're getting is state in your application container and that's always a bit problematic Yeah, it's not really to a factor and it gets messy there So we talked a lot. What's the life cycle we talked from the open service broker api It that thing you fetch the catalog as with With your uh create service broker, um call, which is the operator is doing It goes, uh, you tell there's a url On the behind that url you find the service broker. It has credentials that are these platform fetch the catalog of that service broker What are the offerings of that? Then later on a customer can do a cf marketplace to look up which um services are offered And it says I want to create that service in the background the cloud controller says the service broker provision one instance So we get spun up a mysql database um later on it says bind my servers Bind that service to my app So we create a binding in the background Maybe it's created a user on that database a password for him and provides that back to your application Later on I say unbind that service and the service broker may delete that user on that database So the application even if someone grabbed the information the user credentials from that app environment is not able to access the database anymore with it And in the last we say delete that service because we don't need that database anymore and the database in the background is deleted by the service broker And this flow is always the same. That's the open service broker api the flow in the middle So it's all about rest calls and it's all about getting the interaction between um these two so there are also additional um optional interaction possibilities with the between cloud controller and the service broker above The ones I showed are the most important ones So why the hassle about service brokers and What are the use cases I can do? first of all If you look at database for example, we could have there an existing Service maybe a database cluster, which is already there and I want to provision the in there My service instances. So what I'm doing is I go to my dbms. I say create me a new database in your class in that cluster That's creating a service instance Or I want to maybe and then the binding would be create me user on that database Or second use case I have I want to have a single database instance, which is dedicated for my for my customer Which is a single VM. I spin up if you create a say create service instance So in the background, I do something maybe like bosh create an Vm spin it up install my dbms system on it and also creating the database in it And in the second step when the binding comes I do the same stuff I did like with the existing cluster, but that's a single instance for my application That could be something for load tests integration tests Why I don't want to hassle with the others or it could be something with With routing with load balancing with firewalling or whatever And the second thing could be then I like I did the existing dbms cluster I could also spin that up for one customer with a create instance So I instead of spinning up on a VM I spin up a high availability database cluster And get that running it could all where all the same things could be create service instance You can all these things hide behind that Abstraction idea so create service instance can mean many things So the big question is if I'm stuck with that problem I need a new service in my platform. I want to provide that to the developers Do I have read to a re-implement that whole open service proper API stuff? No. Please don't everyone re-implement all that service broker stuff for the life cycle There are frameworks out there Please use them because most of the code in your service broker is always the same There are frameworks for go for Java and other stuff use them because they have one benefit They already implement the service broker API perfectly Maybe there is a bug in it make a pull request let it be fixed Make a so use it for example my company is doing one of the one of the Java frameworks for you If you're interested in contributing, please do that. We are happy for contributors But it's open source. You can use it. Please do that So for example our framework works like that all the blue stuff The management of the catalog the creation of the service instances the creation of the service bindings Storing information about your service instance in some database in the background I'm talking to OpenStack Docker some existing service Bosch It's done by the Kubernetes. It's done by that Framework even these stuff here. It's already there. You have to choose what you want to use but you have it's there and what you can focus on is What does create a service binding mean for my sequel and that's the sql commands So this creates a database and this Creates users in it and deletes it So you only plug in the minimum amount of energy in creating a new service broker and what you have to provide is this For example a Bosch release deploying your database cluster or something like that Yeah, you have to do that, but you don't have to re-implement the Bosch API So Thank you. Well, let's make a jump to another topic service key management We talked about app binding binding it to an app with a user So but maybe at some point of time There is the point I need for debugging or for migration of data I need to direct access to the database at some point because It's databases. They're stateful. They're problematic And I don't want to do that as an operator of the platform doing the service broker That's stuff the application people should do because they know what they're doing in the database with the with their data What the application does if they might need to change the table It's not stuff that should be done by the provider of the service broker It should be done by the people doing the actually the actual stuff the project which is making the app So There's service key management. So New problem. I'm a developer I want to access the service That's what we did Now we want to do that So instead of Doing the information about how to access putting to the user and to the application. We want to put it to the user How would we do that? easy We exchange two parts of our lifecycle It's instead of create a binding a bind service delete service We say create service key Delete service key And there's a command in cfc li where we can look where I can look up the data The credentials to access them so I can look up I create a service key and look up that key and see what are the the access data to your application There are two possibilities What to have to do then to migrate your data first attempt The service broker creates a wonderful way that the data he's providing you are already accessible from your application developer side Because that database may never have or never should have a public IP address accessible from the internet But your developer is coming from the internet maybe So what you have to do is do some stuff that you can naturally access that So the IP address or the domain name he's get presented in that service key to access the database is Already accessible from the internet and if he when he deletes the service key That access will also be deleted. So you put that in the service broker The other temp is It's all local You do that, but what you also do is You create and container on app or a task And put that thing um Use that with cfssh and make an port forwarding through cfssh which works like you used to from ssh So you make a dash a big uppercase l And put the ports through and then you could access so that works If it isn't disabled by your platform operators So there are different approaches to that or you can say no, we don't want to do that And so the service broker people have to do the migration stuff So what you're doing essentially what I told you is the service broker in the if you make that public accessibles thing is doing that the cfx If you say it's create a service key the app a service broker is shifting some public Accessibility to that service instance and may shift it accessible in the internet Maybe with some proxying or some stuff And later on it removes that Think about what you're doing you're making your database accessible to the internet from the internet um Or You say there is an air gap um So you have to do the jump with a question mark through cfssh And the service key information is only another user. So when the service key is deleted No, one has access anymore with that data information to their instance so Now we can access interact with our application. We get a service spun up um But We heard a lot a lot about distributed infrastructures on that conference now we have platforms with cloud foundry installation and kubernetes installations all over the place they could be here that could be 500 We have for example a t mobile in the keynote today. They said they have 19 regions So these are different cloud foundry installations Where you everywhere have a marketplace and you have to Handle that so what you're ending up with is you have a user different cloud foundry installations They have both private networks and they're both exposed to the internet The user is living in that internet And first attempt is you have at each side a service broker which creates its own services They're not shared. They're not connected So you If you want to have data at both sides you have to find a way to Synchronize that at application level Second attempt is you have a service broker at each side. So it's accessible locally for you For your platform and you have some central service Maybe at some big cloud company like ibm the watson stuff or you have google cloud cache or some something else you want to use in your On-premise cloud foundry installation Then you have a service broker on your side accessing that service which is in the in based in the internet or in some central data center or something the third approach The service broker is at that side where the service lives. So All the platforms access this external URL because for cloud foundry the service broker is a URL It could be in the internet if you the cloud controller can access it It can talk to that service broker and that manages the public service available service and The most problematic part where it's get really messy Is distributed internal services so service brokers at each side They're producing services And they have to sync automatically the service brokers have to make up that linking So if I create a service on the right side and I create a service on the left side Magically they're stuck together and there may be a message queue Tunneling messages from one side to another But that's really messy stuff You have to have a very fit team of engineers doing that service broker stuff because You have to come up with this trip. It's distributed services. It's distributed state And this has to be spun up for you automatically. That's not easy Be careful when promising that to your users That's really hard You can do that it's possible, but it comes with Assumptions from the users. Oh now our data is always aware available at both sides Maybe maybe the latency kicked it off But There it is getting out of the focus of special applications from the general route to special applications. So There are many talks at that conference many other videos. Have a look at them. There are several Projects I'm trying to solve that problems That's not one-on-one anymore So When I'm doing my service broker, what are the pitfalls? What can what can I make problems with? Um That differences I try to hide them But there are different kinds of deployment of my service by my service broker If I want to unify that in one service broker that service broker gets complicated So use frameworks What else Multitenancy If you deploy a redis and you want to make it multi-tenancy possible happy fun because You have one password For all of it all the users all the connections It's one password if you want to have multi-tenancy you have to spin up another redis service with another password You can do that on the same machine. Maybe share that VM, but it has to be another process And so multi-tenancy is a really specific part of that special service A part in your framework. So it's it's really depending on that special service how to do multi-tenancy And it's really hard for some services to get that so from the different kinds of offerings I want to do Maybe some are not well suited for all of the services um Because multi-tenancy I may have to introduce by a Making these two's I cannot do that in existing clusters I may not want to share them But I can maybe spin up new instances per user So making new redis database for each one could be possible and you're fine with it um capacity bounds Really interesting when you're getting to databases The big old databases are really good at enforcing capacity bounds The new data businesses aren't that often They may are able to say or you can at least at max do that amount of of disk space But you're not able to limit memory or cpu so If you share some Some existing cluster You may have the problem that one user is grabbing all the cpu cycles and the other customer having issues with that And so if you do operations for it you get problems to see oh, we have that bad customer We should put him on a personal one a cluster and don't put him on on the existing shared one um session management There is normally an maximum amount of sessions each instance can do and for some services um The if the the connection is closed by the client It's not obvious for the service that it is closed So it keeps the session alive and it pollutes the amount of of sessions the service can hold So you have to have in the background some stuff like killing sessions that aren't used for some time or some stuff You have to do that and it's not part of maybe not part of the service broker It's not part of the Of the service broker api, but it's part of how you deploy the service. Maybe it's Something you have on your bush release. Maybe there's a process looking up if I have to kill these old sessions um That's the two operations like also like backup. Yeah, and this whole we talked about we didn't talk about backup But you have to have that So you have to maybe implement it maybe provide that possibility to your users With your service instances if you look if you have a service instance You make cf service service name and then you see the information of your service. That's always the possibility. There are two fields one is documentation There you can put in url where your users can find information about that service how to use it properly And there is in a field which shows you um A dashboard Use that because there you can make a backup management configurable or something like that, so These urls are shipped with a service instance creation to the to cloud front or kubernetes and then They can provide that to the user So he is able to manage that service instance to some point um also problematic version updates because ha Postgresql has some security issues. I want to switch over to the next version of postgresql. But because there it's fixed Okay, we deployed that service instance VMs automatically with bwash So we now have to manage the update of it but updating it maybe breaks some of the Specs of that database so some functionalities are were deprecated aren't available anymore So that has to be some some to some point visible to your To your consumer to use the application developer because he has to know when the switch happens But you may not have a service broker team have a back Communication channel back to your user um So what you have to do What you can do is there's the command update service instance Which the user can do so there you can maybe provide another plan Which you can update his service instance too So he switches from his old plan to the new plan with the new major version of postgresql Or maria maria db or whatever So you can couple of that in that part of your service instance lifecycle Plan changes you offered something now you don't want to offer that because it made too much issues Or you want to change what is offered with that service instance, but the service instance is already there That's a lifecycle management. You have to come up with Also, what is problematic is what to put in a service and what to put in the service plan What is part of services across several plans and what is part of a specific plan? You have to make that decision first If you want to make a service broker, you have to have a plan what you want to offer What is the service and what are slas but because slas are service plans Do I want to have existing clusters single services for tests? Instance for test do I want to have specific clusters for something? What do I do? What what is the service at its core? It could also be an email send it out to operations who do some stuff. Yeah, that could also be the service Create a ticket at some backlog whatever Have in mind first what you want to achieve Then start with the service broker Also monitoring of the Automatically created stuff. Yeah, you have to Plug that into some monitoring Also for maybe for the customers configuration management You may want to change configurations of that existing stuff. So you have to have a plan for that I'm only talking about these stuff because service brokers Aren't that simple on the first thing you have that simple api you have only to implement But why are we doing service brokers? It's because the stuff we didn't put in cloud foundry is the stuff that gets Really hard to maintain state is hard to maintain So we're putting that out of cloud foundry. So we have to make up plans how to maintain that outside in that service teams Um and part of it you can put in the service broker parts You can't but you have to make your decisions about it to be clear what you want to achieve with the service broker first and then do it often what happens management comes to product team We need a service in our market place do that. Please do that Come up with a plan for it implement it ship it to us And do it and then the the the guy is here. Okay. What's the service broker? Okay, I understand that api. I'm proliferated. Oh, I made a buck with the implementation Oh customers complaining that they get wrong errors from cloud foundry with Some mysterious messages that the service broker didn't work like cloud foundry expected. Okay Now now i'm using the framework. Now it should work. Oh, dude, you is hard Don't do that make the plans first Get people to know how to run that service how to manage it and then Ask them how to automate that processes and then put that in the service broker Make plans first then do the service broker And don't forget tests There are contract testers Out there for testing that your service broker implemented the specifications My company has one we're talking nowadays to make that officially Maybe that link changes to officially one of the open service broker api in the next days We're talking about how to do that best or if we want to Manage a list of available service brokers that are actual and maintained on the open service broker's api's list page Look out for these there are several at the moment. Um, we're checking if we Focus on one or doing difference If that changes that we will push the code maintenance on open service broker We will put a link on that address so we can find the new wash These are contract tests They only show that you keep the lifecycle correct so that cloud foundry correctly can Communicate with your service broker That doesn't do Smoke tests with your service broker services that doesn't know if the service you're provided you're created Is up and running after the it made the create instance and the service broker said yeah, i'm done Do these tests also and do it. It's crcd. You're creating a product here Test it Make lifecycle tests. It's like you're doing an app if you provide a database here a database creation automation you have to want to have Tests for it like you want to have it for your application So that could be for for example a crcd pipeline making the contract tests with a service broker Then making another set of scenario tests where you Create an instance and then have another app deployed which tries to connect to that service instance And if it fails you have done something wrong and if it's good you know that at least this application deployed to cloud foundry in a Test environment is able to access your service So if there are other customers say we can't access that it doesn't work for us. You can say my app does Let's talk about the differences. What do you do other than me? so Last but not least You know that 12 factor applications the apps you're deploying to cloud foundry. That's fun Your service broker can also be in four factor application But your databases may not Think about that what we're doing with the service broker is we are making Up from a service software as a service perspective down in the stack To maybe infrastructure as a service or hardware as a service or something. Yeah We are doing a depth adapter or here so Please be careful with it Have you make up your minds before doing it and doing it correctly In the first place because if you're providing service and customers think it's not working Their customers they go somewhere else. They complain You want them on your side. You want to make them happy. So think about that think about user experience when you create a service broker So that's us You can reach us to us if you have questions like I said Ambassador happy to answer your questions about cloud foundry and especially service brokers and services Yeah, if there are any questions come out with him Elsewise I'm out there And I'm available on the conference like here when I'm here. Thank you