 As Ben points out, we know we're the last people keeping you from beers upstairs, so we promise to be quick and hopefully interesting. To start with some introductions, my name is Matt Magnini. I'm the product manager for the open-source cloud foundry services API team and one of the co-chairs of the open service broker API project. Hi, and I'm Nikola Masłarski from SAP currently working as a software engineer on the services API team. So the agenda for today, I'm gonna start off by telling you a little bit about our team and what we're aiming to do for cloud foundry. Niky's then gonna take us through what we've done in 2018. We'll then talk about the future. A quick intro to the open service broker API in case that's new 21 here, and then we'll do a quick live demo, which will hopefully work. Cool, it's okay starting with our team. So that is all of our wonderful faces. We are based in four different countries in three different time zones in Europe. We are a very remote friendly team and have contributors from both Pivotal and SAP and our goal is to improve and maintain the end-to-end services user experience in cloud foundry. So for those familiar with the cloud foundry CLI, every time you type something like CF create service, there's some CLI code that that runs through, that then talks to the cloud controller and finally the cloud controller will go and talk to some service brokers to get them to do some things. We're a bit of an unusual cloud foundry team because we don't own any of the code bases in that path. We contribute to all the components in that path though and try and own that experience rather than owning any code bases. Since we're heavily dependent on the service brokers, we work with the open service broker API community to help improve that specification, help guide it to add some new features and then make sure those features are implemented in cloud foundry. So that developers who are using the platform can get the hold of them and now Nicky's going to talk through the last year of SAPI. So, yeah, out of a lot of things I'll have to go through the most important of them and the beer began with service instance sharing, which was a very requested feature because until now imagine you have a service instance in one space and you want to consume it in an application in another space. Well, until now the only way to do that was by creating a service key and manually importing the credentials in the applications environment or by using a user provided service key, service instance, sorry, and as we all know copying and pasting credentials isn't the most convenient thing these days. Well, now you can simply share your service from one space to another space and bind into the application there. This was released at the beginning of the year as experimental and after collecting and implementing some feedback now it's GA since August and you should remember that for service to be shareable both the platform and the broker has to enable that. Next thing on our list was providing developers with more visibility into the service instance and binding configurations. Well, this is important because imagine you have a service instance that was created somewhere in the past and now I want to update it or recreate it for some reason. Well, I have no way of knowing if it was created with some configuration parameters and what their value was and if I want to recreate it maybe I would need to pass the same values to be consistent or something. Well, earlier this year Open Service Broker API introduced an endpoint on broker side where your platform could fetch these parameters and this is now by now fully supported by Cal Foundry and in the next few slides I'll show you UI that's already taking advantage of that. Well, this is how it was before now I have my Redis here and I want to update it, but I don't know how to configure that instance or how it it was configured in the past and nowadays I can see that it was created with 10 nodes. Going up with one of our biggest features of the year and that's asynchronous bindings and unbindings and why is that important? Because our platform has pre-configured timeout for operations like this which is normally between 40 and 60 seconds and if your broker happens to have a long-running operation on its bind or unbind maybe it's provisioning something or it's calling an external service, it might not finish their quest in time so the binding would fail and now the broker could simply support asynchronous binds. This is also our first step towards supporting Google's cloud services on Cloud Foundry since their broker is async only but we need, there was more work needed to be done in order to support Google's services since the Google platform service broker supports only special type of OAuth authentication and Cloud Foundry talks to brokers only in basic Alph. So we developed a proxy broker application which talks to the platform in basic Alph and to the broker in OAuth. Well, with it you can take, your ops can take advantage of all the Google services including Spanner and now I'll be leaving you with Matt to talk a bit more about the future. Thanks, Nicky. Okay, so the future is basically the roadmap for the services API project, which is obviously subject to change and if you have feedback on it or want to change it then we'll give you some links at the end as how you can get in touch with us. So the feature we're currently working on is called multi-service registration. In reality, this means we are allowing the same service name to be registered twice in the Cloud Foundry marketplace. We're doing that for a couple of reasons. Firstly, as you can imagine, there are many service providers out there wanting to build things like MySQL. Now up until now, if an organization wants to do or a Cloud Foundry user wants to use two different MySQLs from two different providers the first time the Cloud Foundry admin tried to register the MySQL broker, it would succeed and the second time it would fail because those names would conflict. What we're allowing is for that name conflict to not happen and then the marketplace can have two different MySQLs but we'll also see that the providers or in other words the brokers that those services are coming from. So when developers do something like CF create service, MySQL instance, they'll be able to choose from two different companies or organizations where they want to get that MySQL from. The other reason it's important is because now this allows you to register the same service broker twice. So that sounds quite funny. However, we do allow these things called space go brokers where development teams without any admin rights can go and register a service broker into the marketplace just for their specific space that they operate in. We're seeing a kind of trend in the industry right now towards these kind of hosted or managed service brokers. So examples include Amazon's AWS service broker, the Google Cloud broker, Nicky talked about, and the Microsoft Azure service broker and typically these are used or when you register these you want to provide some authentication and typically that's done through something like a service key which is relevant to your development team or even that individual developer for various reasons like auditing and billing. By allowing developers to register the same broker twice you can imagine a scenario where two different development teams in different spaces both want to consume Spanner through the Google Cloud broker but they have different service keys to access Spanner and now they can both register it with their own credentials. Next up is improving platform to service broker security. So today when you register a service broker only basic auth is supported. So the admin doing that registration provides a username and password. We want to improve that not only to provide better security between the platform and service brokers but also we want to give fine-grained access control to those to the resources you can get through a broker. So up until now if you can see that a service like my SQL in the marketplace then as a developer I can do everything from provisioning it, updating it, deleting it, getting access to it and revoking my own access to it. We're seeing a demand for more fine-grained controls where different developers or even different teams might want to provision it or update it but then someone else is actually getting access to it because they're responsible for deploying their workload on Cloud Foundry. Next up and a pretty meaty one is called generic extensions or also called generic actions. This is an extension mechanism for service brokers to define a list of custom actions you can perform on the instances that have been provisioned through that broker. The most common use case we hear for this is customers want to do things like backup and restore their service instances, especially in the case of things like databases. The problem is that backup for a service like my SQL looks very different to a backup for a service like Redis. And even if you just take my SQL there are many different types of backups you can do and there's no kind of uniformity in terms of the parameters that you have to provide, the destination as to where that backup artifact is going. What this mechanism does is allow service brokers to programmatically define a list of actions that you can perform on any instance that they provision. So we might see things like backup and restore. We might also see things like start and stop or even some completely custom action like changing the leader node in a my SQL cluster. The other exciting thing this allows is since the way this proposal is written in the Open Service Broker API is that it allows commonly used standards to be defined as actions. So let's say we had a standard such as a Prometheus metric collection standard. A platform like Cloud Foundry could automatically look at all the instances that it's provisioned, see all the ones that support that standard, collect them all up and aggregate them and then stick it into one kind of Grafana dashboard. That would allow kind of these service operators or the people responsible for managing instances to have one place where they can see the kind of the health or the metrics of all of the instances that have been deployed from any broker in any number of their Cloud Foundries. And I think last up is automating network configuration for service bindings. So for those more familiar with CF today, when you bind one of your applications to a service instance, typically that binding that you get back from the broker contains things like credentials and IP address and maybe some other metadata. There are other types of bindings available. Volume mounts is one example where you can mount a remote volume into your container. But almost all the different types of bindings that exist have one thing in common, which is your application, which is hopefully some 12 factor app needs to talk to a third like an external backing service, which may or may or may not be running on the same infrastructure as your application. For bindings that return IP addresses, what this requires today is for an admin to go and change the application security group or ASG in that space so that it allows the container or the application to talk to that third party service. What we'd like to do is one have that happen automatically. So if the platform trusts a broker, then when it gets back a well structured binding, it can automatically open those networking IP addresses or ports to ensure the communication can happen. And secondly, we'd like to support DNS names in those bindings. IP addresses can change. If we use DNS names, then those bindings will be much safer and we won't have to be recreated intermittently. All right. So by now, we heard about Open Service Broker API a lot, but what is it exactly? And it's the community's attempt to make broker to a platform or platform to broker communication generic so that when you develop a service broker, you can deploy it on all platforms and use all services everywhere. And Matt, as part of the OSBAPI working group, will tell you more. Yeah. So as Nicky described, the specification is the kind of separation point between platform authors. So people like our team and people working on Kubernetes and service providing authors, people writing things like MySQL and Redis. What we, kind of the goal of the project is to allow any service provider to write their service once. Not worry about which platform is going to consume it. And then by using the Open Service Broker API, Kubernetes and Cloud Foundry and hopefully more platforms in the future can all make use of that service. It's very simple. A simple service broker contains five endpoints. One for fetching the catalog of the service, so saying, hey, which services and plans do you offer where plans are typically t-shirt sizes? Two endpoints for provisioning and deprovisioning a service instance. Sometimes we see provisioning used by service broker authors to spin up a new VM, running some software. Sometimes it's just cutting a slice of an existing VM. And sometimes it can't be nothing at all. It's just an abstraction we provide in order to try and make any backing service work with any application. And the final two endpoints are binding and unbinding, which really translate to give this application or container access to the service instance and then revoke that access. All of the features we've spoken about today other than service instance sharing feature have required support in both Cloud Foundry and Kubernetes. Our team is responsible for adding support to the Cloud Controller for Cloud Foundry, and there's a service catalog project which has implemented those features in Kubernetes. OK, and now it's time for the demo. To help you make a little bit more sense of it, we have two slides just explaining what's going to happen. So this is a world some of you may be familiar with, where Jane's got this awesome service. She's called MyService, because that's a sensible name. And John has heard about MyService and thinks it's awesome and wants to bind his application to it. However, when he asked Jane for that, Jane says, well, I can email you over some credentials by using a service key, but her security team is going to be pretty cross with her if she does that. What this feature allows Jane to do is type CF share service, specifying the name of the organ space she wants that service to be shared into. And then John can simply do CF bind service and give his application access. And if this Cloud Foundry setup was using something like CredHub, then neither Jane nor John would ever have to see those credentials. So this is a very secure way of getting applications accessed about the backing services they need with no copy-pacing of credentials and no one kind of looking at logs or running CFM and trying to get access. All right, terminal time. Right, just a quick note up front. We've deployed all the applications we're going to use for time-saving reasons. And first, we'll need to register our broker in order to have a service in our marketplace. Let's begin with that. If I'm typing too fast, you can just ping me. And if you need to have a look at some command more specifically, you can just ask me. OK, we have to enable our service towards the Cloud Foundry. And if we check our marketplace, we now have a service. In order to share it, like I said, the platform has to allow that. So it's a feature flag. As we can see, it's disabled by default. We can simply enable it because we're admins. And OK, we can begin. We have two spaces. One is source. We're going to create the service there, bind it to an application, see that it works, and then share it to a space called target. And see that the service works there also. So we're creating the service now. And if we check the service, we see that the service says name is MyService and the service is of type. Overview service is plan S, simple plan. Now, binding it to our application, we'll have to restart it for the binding to take place. This happens because the way bindings work in Cloud Foundry is as environment variables and our application will have to read it. After that, I'm going to show you the application's dashboard, which actually shows what binding it has. Well, opening it, now we can look through the dashboard. We have the application name and we have the space where the application is located. We see it's in source space and we have the service bound to it. The service of type overview broker and the service's name is MyService. We can also see the plan. All right, going back to the terminal, I would want to share my service into the target space, as I said earlier. Now, if I look at the service, I can see that it's being shared to org development space target and it has zero bindings there. So now, we can go to our target space and if we check the services, we see that the service is now here. It's the same service of type. MyService is the, okay, the name is MyService, the service type is overview service and if we look at the service itself, we see that it's shared from development org and source space. Now, let's bind it to the same application and we'll have to restart the application, but one more awkward minute, we'll see the dashboard and hopefully we'll see the same binding, but to our new application. Okay, now we see our target applications dashboard. We see that the application is called target app in space target, but we have the same service bound to it. How cool is that? Now, going back to the source space, if we check the service, we see that it's shared in the target space and it has one binding there. Now, because we're bad people, we're just going to share the service and that will delete the binding and I think that was our demo and it worked. We can deprovision. Thank you very much. Okay, so as I mentioned earlier, feedback on that roadmap and things would be appreciated, so how can people get in touch with the SAPI team? Yeah, we're very open to feedback and future requests. You can get in touch with our Slack channel on the Cloud Foundry Slack, hashtag SAPI or by the email you see on your screen. And there's also the open service broker API logo down there. We're looking for feedback from both platform authors, so if you work on CF or Kubernetes and also service broker authors, even if you're looking to kind of offer out a service you own or run at your own company to the other development teams in your company, the open service broker API can be a really nice abstraction to let you do that and really run your service as a product. There's a 10-minute slot at the start of every weekly call where we ask the new faces to introduce themselves and listen to your community, like we call it community interests. You can bring any problem you're having or any question to the group. That's at 5.30 p.m. in this time zone and you can all work out based on where you're from. And I think that's it and we have six minutes for any questions or there is beer. That's not all. We'd also love to see you at our other presentations or the hands-on lab that's tomorrow at 2.10 where you can get your hands dirty with QuadFoundry and Kubernetes and see how open service broker API works in real life and also visit the project towers again tomorrow at 11.55 p.m. Cool. Any questions? Thanks. I really love the new feature that you can share, service instance. But what about when I share it with the space target and developer in the space target would like to delete the service? Yeah, so as you can imagine, this was a common source of feedback when we were trying to kind of originally solicit some feedback on this subject. The approach you've ended up on is having a service appear under like CF services if you're not binding any apps to it is kind of, it's not too harmful. It's a little bit cluttery, but hopefully as nice humans you could like run CF service in order to find out who shared it with you or at least which organ space it came from, right? And then reach out to them and be like, hey, we don't need this anymore. Do you mind on sharing it to help us clear out? The alternative would be allow them to delete it from that space. What we really, the thing we found when I'm kind of asking for feedback on how to build this feature is kind of what controls do we leave in the hands of the person who created that instance in the first place? So the things we didn't show today was only developers in that source space can do things like CF update service. And as Nicky showed at the end, when they did CF unshare, if you don't use the force flag, a big warning comes across the screen saying, if you do this, then you're probably going to break someone's app and someone's going to shout at you pretty loudly. But we've done that in order to leave as much control to the person who created the instance. Because in real life they're probably the person paying for the underlying infrastructure and the person responsible for managing it. As a, if I receive that in the target space, if I had access to that source space, I could go and unshare it, so I could clean up myself. If not, though, the only things I can do is bind and unbind to it. Thanks. But it's good feedback. Yeah. Any more questions? There is a question over here. So you just said the service broker API works for both CloudFonger and Kubernetes. Now there are its functions. So do you see a user case for the function, the event-driven functions, to use the API for the remote services? So to use a function service to integrate with these. Yeah. So there is work being done there by Pivotal. And I think we spoke about this earlier. I'm not sure if SAP are looking at this. Google are definitely looking at this. So when you run up that function, you can declare in a manifest, a broker lives here, and here's a service and plan. And actually when my function runs, I need to go and provision that thing. And somehow use it, right? You can imagine like some demo this morning if it was some text to voice converter, you can imagine a function that wants to make use of that. Because typically, at least in what we've seen, functions need to run pretty quickly and then spin down. Service broker is today at least optimized for creating new resources. And then they hang around for a long time and you bind and unbind to it. It's an interesting question with the functions thing, because do you want to create a new instance right then and there, or do you want to reuse an existing one? It's early days, I think is the answer to that. It's definitely a use case we know about though. I don't know, at least at Pivotal, we have teams looking into what's the optimal path for that flow. Any more questions? If not, thank you very much to Matt and Nikolai. And let's have all fun at the booth crawl. Thank you.