 Welcome, everyone. I think everyone probably came to see Josh, but I'm going to kick things off. My name is Colin Stephenson. I'm with Pivotal. I lead our partner architect team. And so when talking to Josh about the open service broker API, which hopefully you'll hear to learn more about, we thought about, is this really necessary today? We work with partners. We talk with ISV vendors, with system integrators, our various cloud provider partners within the Cloud Foundry ecosystem. And the open service broker API, there's some questions about it. Is this overkill? Is this something that we really need to be doing today? And if we look at the history of service-oriented architecture now moving into microservices and how we're provisioning these and interacting with these, my proposition is that this may not be necessary. And so Josh is here to prove me wrong. I'm a huge fan of the open service broker API. I think it is the most important thing to happen in computing sense object-oriented programming and probably more significant. This is basically like cats and dogs living together in perfect harmony. It's like rainbows and kittens falling from the sky. So the best thing ever. And paradoxically, it's essentially like hell has frozen over and we're all going ice skating. How many of you have heard of the open service broker API? OK, good. So picture this. You can take an Oracle database product run by Microsoft and connected to from on top of Google's cloud. So if you had predicted that to me a few years ago, I would have told you like that will never happen. That is the most ridiculous idea ever. You can take a Microsoft database, run it in Linux, and deploy it on top of Oracle cloud. You can take Google's database and connect it to applications running in vSphere. Like you can mix and match service brokers in ways that their authors never intended. In fact, that I don't think anyone ever intended. And so this is exciting. This is beautiful. This is freedom. I don't know. I don't know about that. So if we, yeah, you're reading down to the bottom already. If we look at the term service, and we're talking about service brokers, right? If the term in Latin servidium goes back to talking about slavery, are we just talking about slavery brokerage to these different technologies and these services? I'm a little concerned here. We looked at all these big logos from these large vendors. Are they just honing us in into some new slavery of API service provisioning? I don't know. I'm a little concerned here. Let me cast aside the shackles for you for a second. Let's talk about great moments in technology. And I mentioned object-oriented programming, but I'm going to go back further than that. So if you think about the invention of programming as a discipline, I don't mean Turing, and I don't mean the invention of the computer. I mean Steve Wozniak. Hear me out. With the invention of the Apple computer, it was the first time you could be a software engineer without understanding hardware. It was the first time, and it was actually my first computer was an Apple, you could not know how the hardware worked. You didn't have to understand logic circuits. You didn't have to understand the physical memory or the CPU or what a logic gate was. You just had to understand programming. That was a really powerful abstraction. It took software development and computer programming from the domain of thousands of professionals to millions and tens of millions of enthusiasts. It actually opened up an entire field. And that we did that by creating the separation of concerns. We think about highways. If you want to go really, really fast on a highway like the Autobahn, you have separate lanes. Traffic goes in one direction on one lane and another direction on another lane. This is a very powerful concept. You keep these things separate, they don't crash into each other. There are other great examples of this. How many of you are programmers or have written code? Okay, how many of you have ever used MVC? Another great abstraction written by a man whose name I can't even pronounce. Which is because I'm American, I'm sorry. Xerox PARC 1979, right? The separation of, oh, I don't know, logic that relates to the front of the program, from logic that relates to the back end of the program, the separation of data and logic. A super powerful concept. So when we separate concerns like this, we end up accelerating both teams. If we get the abstraction right. Let's look at another one. Let's look at networking. The entire software-defined networking movement over the last 10 years has been powered by the separation of the data plane from the control plane. Packets move in the data plane, deciding the rules about where those packets should be routed and which ones should be allowed and which ones should be transformed happens in the control plane. We can keep the data plane really, really fast by separating the control plane from it. That's actually what the open service broker API does. It's the control plane for data services. So we're applying that same magic of the separation of concerns to these shackles, the relationship between state and stateless, the heart of the cloud native movement is separating these two things. But we still had the control plane logic stuck in the data plane. So I mean, this should be enough convincing for anyone, right? Even you. But I'll give you one more concept here. The word broker comes from broaching a wine keg. So the original brokers were wine merchants, which already, I love the concept, right? But even more importantly is tenancy. If you have a single wine keg, it's yours. It's one person. It's a single tenant model. As soon as you have a broker, you can share that wine keg with your friends one bottle at a time. This is really important. As soon as you have a service broker, you're making it easy to provision multiple copies of a service with different credentials. You're creating a new tenancy abstraction. And in fact, it gives you a way to take advantage of the divisibility of your underlying resource. Wine is infinitely divisible, but people prefer to have their own wine glasses. So far, you've convinced me that I'm ready for one of the beers from the SAP booth out there. Day drinking is the hallmark of all great programmers. Yes, exactly. That's not actually true. So I get the excitement, we're getting there. But then I look at some models, right? You look at Apple, maybe some other technologies out there where they're able to successfully go from generation to generation. They can even mix up the interface and the protocol that you're using. And people will still buy it, right? It's perfectly fine. You get some complaints, right? Maybe some forums with angry customers that throw their iPhones away and go buy an Android or something. But for the most part, that mark is still there. And even though the interface changes with something open like the Service Booker API, we can, it's not fundamentally changing how our application actually interacts with the service. So you're making something maybe incrementally better in terms of how that service is provisioned. But the application still has to use that service as libraries. We're not completely getting the loose coupling that maybe we desire. So I'm not really sure that proprietary, in some cases still okay, that we can actually optimize the interface for my service, right? My customers are happy. I do care about them. But I don't know if I have to go and now add yet another layer of abstraction there. So I don't know if that's, not quite there. You're talking about this as if it's gonna be a lot of work. And it would be a lot of work if this wasn't an open standard. And it would be a lot of work if this wasn't open source. But the fact is, we fight these risks, these sort of potential lock-ins of saying, okay, well I've made it really, really easy to go use all these commercial vendors. Have I actually just created a new kind of slavery? Am I tying myself into new economic slavery? By saying, no, we're gonna make it just as easy to leave, right? So the notion of rough consensus and working code, this is not a standards effort in the tradition of the W3C. This is not a, hey, we spent 10 years thinking carefully about this problem without ever writing code. And now we're gonna subject you all to that standard. We've tried that before in the brokerage space. That would be UDDI. Or 800 different efforts at soap marketplaces. You know, the difference between XML and JSON, if you're a purist from a parsing standpoint, is like curly braces versus angle braces. But the difference of the life of using JSON versus using XML is huge. And this is the same thing with Service Brokers. The difference between the Open Service Broker API and just a different way to get access to a data service is kind of like the difference between XML and JSON. But I've sort of realized I'm not gonna be able to convince you without showing you this, right? So maybe what I should do is demo really quick. Not how an Open Service Broker works, because I know you're gonna get a really cool deep dive tomorrow when Alex Lay is gonna walk you through Service Brokers and how they can be bound to applications both in Cloud Foundry or in Kubernetes. But since I'm challenging you to build Service Brokers, I wanna show you how to write one. And I think I can demo writing a Service Broker in under a minute. So use an angle there, not a curly. Oh. That's not JSON. All right, scary live demo. Live demos are always a bad idea. Just so, for those of you who've ever done this before, let me start with some code. And I'll try and make it big enough. I actually wrote the Service Broker ahead of time, so I did kind of cheat. I'm writing in Python, not because it's the only perfect language, but- It's the only one you know. Because it's the only one I know well enough to live demo. And because there's a really handy library for writing Open Service Brokers in Python called the Open Broker API. So you can do an import of Open Broker API and then it does most of the work for you, which turns out isn't very much work, but it saves you at least 50 lines. Which, when you're gonna write 700 Service Brokers a day, like I'm gonna challenge you to do, those 50 lines matter. Here is a Service Broker, and all it does is return a catalog of some example services. Cool thing about the Service Broker pattern is that you can have multiple services in one broker. The Microsoft Meta Service Broker has, I think, eight or nine services in it now. And many of them have several different plans and lots of them take configuration parameters, so they really expose a good chunk of their entire Azure data services suite in a single Service Broker. So we're not talking about millions of lines of code here. So I have this. I'm not sure I'm getting enough out of the catalog though, right? I want to make my own choices. So if you're defining these plans within the catalog, aren't I restricted by what I can choose? Absolutely. Yeah. Freedom comes from constraints, right? And you can always write your own. Who's the famous guitar player who only ever had one guitar? I don't know if you have one guitar, but Tom Morello from... Tom Morello. He kept the stuff simple and, you know, but it's just pretty creative, I think. I mean, when was the last time we added an extra key to a piano keyboard? It's been what, hundreds of years? And yet we have new kinds of music produced every year. That's true. There's only 88 keys on that. There's only five API calls here. You could still play a lot of music with five API calls. Fair enough. All right, let's run this ridiculously short simple broker. And nope, it's running. It's on a local port. And I'm going to curl against it just so you can see that I get some JSON back. So I'm curling against the catalog API. And I got my services, service plans back with some descriptions and some IDs. And now I want to show you one of the cool things. There's no Cloud Foundry here at all. There's no containers. There's no Diego. There's no Bosch. There's no nothing. There's just one simple app. And I just curled against an endpoint. Now you can imagine, okay, well, I put that out in the real world. You got to use something other than curl, right? And that's true. And if you're using Cloud Foundry, then the Cloud Foundry Cloud Controller is going to go off and talk to those service brokers for you and pull the catalog and make it show up in the CF marketplace. And it's going to broker off those provisioning calls and that's awesome. And if you're using Kubernetes, the Kubernetes service catalog is going to do the same thing for you. But what if you're in a world that's not just Cloud Foundry and Kubernetes? It's actually a really cool command line client for the open service broker API written by the folks at Stark and Wayne called Eden. And you can just give it a service broker endpoint and some credentials and say, give me the catalog. You get back a simple, sweet little catalog description. You can provision, you can bind, you can unbind, you can get service keys, you do whatever you would do with a service broker and you don't even need a platform. You can just deal with the services. It's pretty cool. Sometimes all you need is a MySQL database, which is an Oracle product run by Microsoft connected to a Google Cloud. All right, we're getting there. All right, now, here we go. So I sort of feel like you believe me. I'm not quite ready to bow down to Josh here, but we're getting there. I think we need to go somewhere with this. Service brokers are cool. Having other vendors make their services exposed in the open service broker API is cool. This is freedom, but most of our data is not in public clouds. Most of our data is in the world is in existing databases. It's in Oracle in the basement, it's in SQL Server, it's in Postgres instances, in some cases it's in DB2, it's in... Mainframes. Mainframes. I challenge you to write a service broker for every single thing in your data center. That's not an app. You can write a service broker for Active Directory, for the key card service. You could write a service broker that operated a internet-connected coffee pot. I actually think that provisioning is an important activity for a coffee pot. Could it write the tap to the wine cake? Sure. Service broker-connected wine cakes. Yes. So I think that, you know, I'm borrowing from other people here, I love quotes. The quote that comes to mind is Bill Gates. This is a service broker on every desktop and in every home, for every device. And I think I've showed you that you could write a service broker in 24 lines of Python. I mean, you probably need another six lines to implement provisioning. And you don't have to write these from scratch. Remember, there's a cute little library for writing them. In Python, pretty simplistic. There's also a very full-featured SDK. In fact, there's three very full-featured SDKs. There's the services SDK developed by Pivotal, that's open source. There's service fabric developed by SAP, open source. And there's Swisscom's confusingly named service broker project, which is for making service brokers. Also open source. Any one of those, and you pick your favorite language and your favorite set of partners, any one of those would be amazing for writing OSB APIs and connecting your coffee pots to the internet. Which, after all, is what the internet was built for. Thank you. That was good. There you go. I agree. We can take on that. All right, all right. We have some time for questions, a little bit of time for a few questions on the topic of freedom, or possibly on the topic of service brokers, or Julie Andrews. Or Julie Andrews. I will actually start singing karaoke if somebody doesn't ask a question, so. Yeah, go ahead. Yep. It's a great question. So here's the guiding principle. A service broker ignoring provisioning, right? You can actually make provisioning a NOOP, if you want. A service broker gives you an endpoint and a set of credentials. So the service that you're talking to can be SAS. It could be a multi-tenant cluster managed in your own data center. It could be a single-tenant instance that's created on demand. It could be any other crazy abstraction of those ideas. So as an example, there was a community member who used service brokers to create arbitrary network connections, overlay networks. So you'd create an overlay network and then you would bind it to apps and they would get a tunnel created from the app or they get reachability, essentially. ACL rules would be applied by service broker binding. You could, you know, you can make these various calls asynchronous. So you don't have to have it be something that returns in real time. So it could be remedy tickets. So you could say, here's my service broker and when I call provision, it creates a ticket to do a thing. Could be build a house. And then when it's done, it eventually updates the status and I say, oh, the house is provisioned. And then when I want keys for the house, I call bind, right? I think having a service broker that built houses would be super neat. You know, you can 3D print a house in like 24 hours. Why would you not have an OSP API connection to that? So it's robots all the way down. Robots, robots talking to robots, yeah. It's control plane. Yeah, so the service broker is only the control plane. It's never in the data path between the app and the service. So it gives you back the details to make that connection yourself. And it's a good question because there's a lot of places where the service broker API could evolve. And you might wanna say, hey, what I care about is a SQL backend. I don't even care which one. So here's a generic service broker for SQL and it's gonna take some parameters or introspect my environment or look up my credentials in some other data store and say, well, I've decided to give you my SQL because you seem like a nice guy. I don't know what logic could be applied, whatever you want, but it's out of the data path. So in a sense, and if you think, I mean, you go one step further and say, well, what about operating those services because the service broker might be talking to Bosch and standing up Bosch deployments. Come on, demand broker does that. They still then have to be managed, right? So there's an operator's interface to those services once they're running. Service broker doesn't care about that. Service broker, the separation of concerns is care and don't care buckets. So in the care bucket is, did I get credentials in an endpoint? In the don't care bucket is, how is the app actually connecting, talking what's the data path like? So is it SQL requests? Is it over port 3306? The service broker knows some of these things and it tells the app, but it's not in the way. I don't think we want it in the way. Now you can write, that's the other thing. The service can be as complicated as you want. So it might, and the broker actually could advertise its own address as the service. And so you could end up talking to the broker and it could proxy off to your data service if you wanted to. So you can have a service broker that also implements the service itself. That's not really OSB. I don't really know why you'd do that. I mean, I think it makes more sense to have a broker that builds houses. Yeah, it's a great question. So in the cloud foundry world, service brokers can be registered in two ways. One is globally by an administrator into the CF marketplace. The other is space scoped. So as a space developer, you can register a service broker into your space and it'll show up in the CF marketplace just for you. So if you write a custom service broker that exposes, I don't know, the post-grade, existing post-grad database you've got in your AWS account and you just wanna make sure your CF apps can go talk to that cleanly and have that separation of concerns around credentials, just register it into your space and then you can create and bind to those services and you're gonna have that service broker just for your dev team. Be aware, you can't space scoped, register the same service broker into multiple spaces. It doesn't work. Although you should file a bug on Alex, so it does eventually. It's not Alex's fault, I'm just picking on him. Yeah, it's a great question. They are, well, let's say they are. They're doing it frequently, right? There's, I think, despite having a lot of large organizations looking at using this open service broker API, it enables a lot of the smaller or newer ISV partners that are gaining ground from developers up in their organizations and these developers can easily pick and choose based on that common interface how they want to leverage those services. So the point is as our developer ecosystem grows, having this common way that they get used to interacting with the services through the broker will make it easier to then how do I figure out exactly which database or queue or house building service that I want for my application. So if I need Mongo today and I want to use Azure Cosmos DB tomorrow, by having that common broker, it's easier for the developer to reason about how they're going to do that or if it's not the developer, to Josh's point, the robot's all the way down. If it's a DevOps team or a configuration management team that's handling those through pipelines, it's easier for them to think about, okay, I just need to go make this simple call to do this. The developer, I assume his code is handling how it needs to from there because it knows it has the credentials and the connectivity to that service. I mean, yeah, to that point, you might not be switching from MongoDB to DocumentDB but you might be going from MongoDB Enterprise to an open source Mongo to Mongo run by Google or AWS or Postgres from the four or five different community vendors that sell managed Postgres tiles now. So the service broker, even if your app just wants Postgres, it doesn't have to know which Postgres. Is it clustered Postgres? Is it single instance Postgres? Is it Postgres as a SaaS service from someone else? Think of it another way. If you have a service broker that builds you a house and you just want to throw a huge rager, right? You're going to provision a new house. You're going to throw the party. You're going to deep provision the house because nobody wants that mess in their own house. Why would you clean that up? Sorry. It's not twisty. Yes, however, I'm hopeful that the OSB API team is going to collaborate now with APIs.json and a couple of these other service discovery JSON based API frameworks to say, hey, we don't need all of this to be new in OSB. We can use Swagger. We can use APIs.json. We can use other things that improve discoverability of an endpoint. So yeah, take your service catalog but make the metadata attached to it rich in this other format, right? The new DDI. Yeah, yeah. The number of catalogs and the number of marketplaces I think is going to proliferate because why wouldn't you? But there's no reason you can't have the description of the broker as separate from a running instance of the broker as separate from the services that can be exposed by that broker. And we'll see what happens. It's a bit like HTML, right? HTML is messy and horrible and decorated with JavaScript and CSS and arbitrary XML and blink tags. I use HTML as a reference because I've worked on several browsers. So just bear with me. It's horrible in all of these ways but it's good enough that it was like the glue in that separation of concerns between client and server that made client and server work for like a third of the time that we've had computers. So I'm pretty sure that this messy pattern of like, oh, it's BAPI and doesn't really have all the discovery we need and doesn't have enough metadata and what about billing and then who runs it and how many copies are there and that messiness is part of what tells me this is gonna work. Because it's not so strictly defined that it's been thought up ahead of time and it can't be adapted to different uses. Yeah. This talk was originally called when hell freezes over which I always ignore the title of my talk by the time I actually get there and give it. When you go to hell and you're not yet dead you have to pay the ferryman. So the payment for the ferryman is that billing and quotas and entitlement aren't in the spec yet. They're coming and Alex I'm sure will talk about where is the spec going so that this can be enabled but it's also that the SDKs, I know the any nine SDK does a really good job of dealing with billing and metering and entitlement. It's not something we've dealt with in the services SDK to my knowledge. We sort of, I mean, if you think of the SAS model you already have an account. You already have an account with Azure. Those account credentials are in back of your service broker call. And so again, it's kind of that separation of concerns. Control plane, data plane, money plane. You know, the money plane is TBD. Maybe I just made that up. I think we're good. Yeah. We're out of time and there's people coming in who want to hear other more interesting people. So thank you very much for your time. Thank you. That was fun.