 Thank you, everyone, for coming. This is introduction to Bosch to Play Services on Cloud Foundry for Cloud Foundry, whatever preposition you want to use. This dinosaur will be present throughout our presentation slides. There's kind of a backstory, but it's honestly not that interesting. I was just bored one day and sad that the on-demand broker had no mascot, so I drew this dinosaur, and then it went viral. So my name is Denise. I work as an engineer on the Bosch team in Toronto. I was the product manager for six months of the services enablement team, which is the team that builds and maintains a component called the on-demand service broker that we will tell you more about. And I'm Zoe. I am the product manager for Rabbit MQ for Pivotal Cloud Foundry, and was previously the product manager for Redis for Pivotal Cloud Foundry, which are both Bosch to Play Services. Do you have the clicker? I'm getting it right now. Sorry. So what are we here to talk about? We're going to go through services and brokers 101. Then we're going to roll right into different options you have with provisioning. We're going to talk about day two operational requirements, a little bit on how the on-demand broker works, some tips to get started with writing your own service broker, and further resources. And it's going to be flashing throughout to see if you're paying attention. I could talk about the intro to services that we're going to do. OK, so we don't have the slides, but this is going to be the audio part of the audio visual presentation. OK, so we're going to talk about services. And one of the reasons for using Cloud Foundry is that it helps your teams go faster. And obviously built into Cloud Foundry is a way to manage stateless applications with Diego, the container-based application runtime. But oftentimes, your applications will need more than that. They'll need persistent data storage, they'll need health checks, they'll need telemetry. And this is where the concept of services come in, and the CF marketplace. So the Cloud Foundry marketplace is a first-class concept in Cloud Foundry. And the idea is that it allows developers to independently deploy and provision service instances once given access to the marketplace by the operator. And one quick thing is we're not going to talk about user-provided services here, by which we mean services-managed off-platform because they don't have the same thing around app developers being able to independently deploy and provision. And they're most commonly used, tend to be used with things where you don't need more of them, let's say, such as a legacy database during a migration. We're also going to just do, if you have a risk of seizures, this might not be the talk for you. But it's strobing. OK, so next we have, OK, we talked about services. And a services marketplace is comprised of service brokers that have been registered in the platform by the operator. But what is a service broker? It can be implemented in many different ways. But at its core, it's a REST API that speaks HTTP. And its primary client is the Cloud Controller. Although, as we'll touch on later, it can be used in other ways. A service broker is also, so here's where the on-demand dyno prefix is important. A service broker is a component that enables application developers to provision new instances of a service for their application when they need it, configured how they need it. Service brokers also provide a catalog of service offerings and plans that you can put on the marketplace. It can be hosted anywhere that is accessible by the Cloud Controller API. And it should follow the OSBAPI specification. And we're going to talk about that in a moment. So OSBAPI, open service broker application programming interface. It is an open source effort to create a strong contract between service brokers and the platform. And if you use the idea is that if you're a service broker author and you are OSBAPI compliant, your service broker can be used not only by Cloud Foundry, but also by other platforms like Kubernetes. So as a quick example for what we mean when we say strong contract, here's an example of a detailed request response that the OSBAPI compliant service broker would maintain or would comply to. So here, it's expecting a OSBAPI compliant platform would expect a 200. And if it doesn't get that, it won't recognize the service broker and application developers won't have access to the marketplace. So the service broker is a way for app developers to be creating service instances. But service instances can be conceptualized and implemented in many different ways. It could be a new table in a database. It could be a new user account in a software that natively supports multiple users. And it could be a new VM. So now let's talk about different models that service broker authors choose to offer for provisioning. And we're thinking about this on two axes. The first is the provisioning strategy where you have pre-provisioned and on-demand. And what we mean by pre-provisioned is that the operator is pre-allocating the resources that will be used by the application developers. Whereas in an on-demand world, while the operator will set limits, application developers are provisioning those resources as they need them. So those are two on the two ends of the spectrum for provisioning. With regard to tenancy, we have dedicated where you have a single VM for an instance or for an instance or a multi-tenancy where you have many users or many instances on like a large VM. So to walk through some examples here, you have dedicated Redis where you've a pre-provisioned dedicated Redis that the operator sets up a bunch of Redises of the same size, makes those available. App developers can then access those. You then have a multi-tenant rabbit. So the idea here is you have a large VM when a new user creates a new rabbit, a new user account is carved out for them. We actually don't have any current examples of on-demand with a strict implementation of multi-tenancy. This is something rabbit is actually exploring doing for Cloud Foundry because there are uses where maybe the benefits of on-demand don't necessarily warrant your use case, such as development or testing. And then here we have the on-demand dedicated use where the on-demand broker chooses to invest its time. And you have a lot of examples of different services that are focused here. So let's talk about some of the benefits of on-demand versus pre-provisioned. So as I mentioned before, the operator in pre-provisioned is pre-allocating those resources. So they say, here's the instance size, here's how many of them there are, and they make those available. And what that means is when the application developer goes to create service, it's actually very fast to get that because it already exists. On the flip side for on-demand, because while the operator set a quota, you need to actually spin up and template a VM, the speed from create service to actually having access to that service can be longer based on your infrastructure. On the flip side, when you have pre-provisioned, let's say you have 10 and you only have two app developers using it, those eight resources are just sitting there doing nothing. And if you have 10 and you suddenly need 15, that's not an easy thing to adjust for, as well as that the actual instances are all the same, and so you can't be configured as they're needed. Whereas with on-demand, because the operator sets a quota, the app developer creates one when needed, and that means that the resources you're paying for and providing are actually being used, or in theory are being used because the app developer has gone through the effort of creating one. One more comment on single-tenancy versus multi-tenancy. Single-tenancy tends to have stronger isolation and security guarantees, whereas multi-tenancy often suffers from the noisy neighbor problem. You know, when you have more processes running on the VM, if I'm like a very good RabbitMQ user, but Denise, a very bad RabbitMQ user is next to me, she's gonna take me down. So Denise, in a world, in a world, you didn't see that, you saw that, in a world with single-tenant on-demand service instances, what operational requirements would we expect? Is there a way to fix this screen? This is an animation now, it's a version. If you're gonna be reading things in short bursts, this is the talk for you. Okay, so we'll try to power through. So, of course, when we're exploring this space of single-tenant and on-demand service instances, before we go all in on this investment, we need some validation that whatever we build is going to meet the expectations that our customers have of how reliable and how maintainable these services are. So I'm gonna discuss a couple of day-to-operational concerns that we would like to, not necessarily guarantee, but be able to provide for our customers. So the first is life cycle management. What I mean by this is whatever tool we end up using to deliver on-demand service instances should have a good story around life cycle management. So that tool should be able to automatically template VMs, create VMs, destroy VMs, and make sure that nothing gets left behind on the infrastructure. You don't want stray IPs sitting around costing you money on AWS after you've deprovisioned that service instance. The second operational concern we have is service discoverability, because now we're working in a world where everything is single-tenant, which means that a service instance means its own container or its own VM. So we need some way to network all of these things together to make sure that Cloud Controller can talk to it and to make sure that they can talk to each other and also to do things like service discovery, DNS mapping, all of those good things. If we choose a tool that doesn't give these things to us out of the box, it's gonna be a lot of pain, like testing out different load balancers and that sort of thing. So the next thing we want is we want a certain level of expectation around reliable upgrades. This means that, so if you're running data services, at some point you are going to need to upgrade the underlying software, because MySQL will eventually go out of general support. So we want a solid story around reliable upgrades. We wanna know that we can ideally upgrade everything and not lose any data, but other things like in-flight upgrades would be a nice added bonus. Oh, went back. So of course we also wanna be able to scale. When you have a surge of traffic to your CF app, you can run CF scale my app, but if you still only have one database backing it, that's still gonna be a bottleneck for all of your traffic and maybe you'll knock your database offline by accident. So we want confidence to be able to horizontally scale that instance, which means to add extra nodes to our cluster if we need to, reduce latency in different availability zones and also to vertically scale, which means to increase the amount of CPU or to increase the amount of disk that your one MySQL has. Of course we also care about speed. Whatever tool we choose has to be really, really fast. So unfortunately on-demand provisioning is always gonna be kind of slow because you're gonna be lower bound by the speed of your infrastructure, but hopefully whatever tool we use won't introduce additional latency. And finally, security. Security is incredibly important. There's an entire track at Summit about this, so I think that this is top of mind for a lot of people right now. So we wanna choose a tool that supports security out of the box. We want a tool that has sensible decoupling between different parts of the system. We want a tool that differs to revealing less information rather than more and a tool that supports encryption both at rest and in flight, which got us thinking. So you probably all know it's coming because the title of this talk has the word in it, but given that we want all of these day to operational requirements to be met, turns out we already have a tool that's pretty good at most of these things. Can you guess what it is? It's Bosch. You totally right. What do you win? I'll give you a high five later. So it's Bosch. So the On Demand Service Broker is a project that Pivotal has been investing in for the last two years or so that leverages all the orchestration power of Bosch in order to provide you on demand service instances for Cloud Foundry. Let's take a quick look at, oh, and also by the way, the slides are gonna be posted there and all the pictures are creative comments, so if you wanna use them for your own things later, I feel free to. So here's some key features of the On Demand Service Broker. So the main abstraction that you need to know is that the On Demand Service Broker maps one Cloud Foundry service instance to one Bosch deployment. This gives you all the isolation guarantees of different Bosch deployments. The On Demand Service Broker also gives you some additional value ads that don't ship with Bosch, such as customizable lifecycle errands. So imagine you are configuring RabbitMQ in a very special way and you need to do some kind of health check after your cluster comes up. You can write that very easily. You can plug a custom shell script into the On Demand Service Broker and have this run automatically for you. The On Demand Service Broker also enables operators to configure both instance limits. So I only want my app developers to request 30 On Demand Service instances and also resource-based quotas. So I know I only have this many IP addresses. Whatever plans app developers wanna use doesn't really matter, they can choose whatever, but at the end of the day, they can't in total eat more than 50 because I know that's the limit of my resources. There's a lot more. The documentation is here. I'll send you the link at the end. So how does the On Demand Service Broker work? So now we're gonna get a little bit more technical. If there are any people here who are interested in writing a service adapter for the On Demand Service Broker, this will be useful for those of you who are here out of interest or curiosity. Hopefully this won't be too boring. So the broker itself consists, it's a Bosch deployment that consists of two components. The first is the On Demand Service Broker SDK, which Pivotal builds, and the second is the service adapter, which you build. So the interface is a contract that has a couple different functions. I'll talk about what some of these are in a little bit, but if you write a service adapter, you need to satisfy the interface of the On Demand Broker. We really like interfaces, strong contracts. So I'm gonna walk you through how CF create service works. Hopefully you've all, hopefully this is not new for anyone in the room. When you create a new instance of a service, you run CF create service, the name of your marketplace offering, the plan, and the name that you want to assign to your new instance. So you have your app developer who says, CF create service in the Cloud Foundry CLI, the CLI will make a request to Cloud Controller who then forwards that request to the service broker as defined by the Osbapi contract. In this case, the service broker is the On Demand Broker. So nothing is strange so far. This is all business as usual. Is it better if you hold it? So this is where special things start to happen. So the On Demand Broker will ask the service adapter binary to generate a block of YAML, which happens to be a Bosch manifest. That manifest is the recipe for your brand new service instance which Bosch will then go in provision. The On Demand Broker will also forward any request parameters, like if you pass arbitrary parameters, it'll send it along to the service adapter. The On Demand Broker is configured with the Bosch Director's credentials. So it actually hooks directly into the Bosch Director API. The Bosch API takes the block of YAML and says, Bosch, give me a new service instance. Here's my YAML. I don't care how. That's how the haiku goes, right? And by the way, when Cloud Controller, oh, I have a laser pointer on here. When Cloud Controller did this, it sent a GUID over to the service broker. The On Demand Service Broker, the ODB will take that GUID and append it to the end of the Bosch deployment name. So that's how it connects CC instances to Bosch deployments. So if all goes well, Bosch will go off in the background and do its asynchronous thing, return a task ID. The ODB will pull that task ID and say, are you done yet? Are you done yet? Eventually, Bosch will say, I'm done. Then the ODB tells Cloud Controller 201 and Cloud Controller will tell the app developer via the CLI. We're good. Here's their new service instance. Have at it. So secondly, I'm gonna cover CF Bind service in a little bit, also in similar detail. So flashing. Okay, so CF Bind service, hopefully you've all encountered this before. You give it the name of your application and the name of your service instance, which already exists at this point. So a lot of this is pretty similar to non-On Demand service instances. So in this case, the app developer says, give me a binding, here's my app, here's my service instance. CLI calls Cloud Controller, Cloud Controller forwards a bind request to the On Demand Broker. And the unique thing that happens here is that the On Demand Broker is actually a completely stateless application. The On Demand Broker has to go back out to the service instance and retrieve the manifest of that service instance because it needs to know the IP address, admin credentials, whatever credentials it needs to create a binding, whatever that means for that service. So once it has those credentials in memory, it calls on the service adapter using the create binding invocations part of the interface. And of course, bindings similar to service instances can be conceptualized in lots and lots of different ways. They're whatever it means for your application to be bound to a service instance to be connected to a database, for example. The design of a binding is totally up to service authors, though. And finally, if all goes well, your broker will return a 201 to Cloud Controller who says, okay, to the app developer. So who's using the On Demand service broker today? So it's not this, it's always using it personally. So it's not really this niche thing anymore. The On Demand service broker is actually used in a number of projects. So Pivotal Container Service is powered by the On Demand broker. It's the abstraction layer that stands up a new Kubernetes cluster, or in this case, a new CFCR deployment every time you run create me a new PKS instance. The On Demand broker is also behind PCC, RabbitMQ for PCF, Redis for PCF, and MySQL for PCF. These are the Pivotal offerings. On the right-hand side, there are also a number of Pivotal partners that build tiles, or build tiles, or service offerings using the On Demand broker. So why use the ODB? Oh, I don't know. You shouldn't know. Okay, that's a sign. So, oh my God, sorry for any seizures caused by this. So, oh my God, okay, I'm just gonna talk. Yeah, I'll just tell us. So leveraging the On Demand broker is really useful because if you're trying to design an On Demand standalone service instance and you want to use Bosch as your deployment layer, if you do this differently, if every team does this on their own, it means that every team is gonna duplicate the same amount of glue work. Like every team is gonna be running bash scripts and passing credentials back and forth. There's not really a way to iterate towards better security or scalability or things like that if everyone is carving their own path. So, I don't know why I'm using the clicker anymore. By using the On Demand service broker abstraction, it helps you go faster. It helps you get a service broker off the ground much faster and you can focus on building services that are fast and secure and scalable rather than doing a lot of engineering around talking to Bosch. So, can we try it again? Is it just off? No, I'm not sure. I think, is there a way to turn it back? Nope. Oh, okay, that's fine. So if you're interested in writing a service adapter using the On Demand service broker, there are two ways you can do it. You can write it in Go, which is my recommended path forward because especially if you use a text editor that knows Go, you'll be prompted what kind of arguments, how many you need, what type they are, when you write the implementations of the interfaces. But if you don't develop and go or you wanna use Java or something, you can just compile your own binary and as long as it has those executables, then it'll work. So, I'm so sad we can't show the picture, but it's fine. You can follow along on your phone if you want to. So, yeah, I had a picture. I just showed you my mug. I was gonna show you a slide with all the dinos on it, but Judy printed me a mug, so I can show you that instead. So, cool, that's pretty much it for our content. If you want to see the slides without... Or at all, for the first time, if you'd like to see the slides, you can go to denise.u.io slash odb. Deniseu.io, there's no doubt. Great, I think that's it. Thank you so much for putting up with us. Also, the other thing I wanna call out is I am no longer the product manager of the services enablement team. That person is Ruth, who's sitting here. So, if you have any questions about the future of this product or the roadmap, please talk to Ruth. Does anyone have any? It's a guy I told her I was gonna do this. There's complaints about this talk. Please talk to Ruth. Anyone have any questions? Do we have time? We probably don't have time. We have a couple of minutes. Thank you all for putting up with the technical issues. We appreciate it. Question, yes? Hello, I wonder if there is an existing testbed for a Spring Boot app that implements, I mean, very simple service broker on demand. Is there an existing Spring Boot app? Spring Boot app that is very simple. Hello world kind of service broker. I don't know of one that uses Spring Boot, but I think someone on, I think Andrea, someone on Zoe's team was working on creating a hello world adapter that's written in Java, which is now owned by Guido Wessenberg's team, the partner ecosystem team. So, if you're interested, we can come talk to me after and I can give you a link to their projects. Is that, does that help? Yeah. So, I'm just wondering how is it different to the service fabric? So, the on demand service broker is an implementation of the service broker API. And there's also the service fabric, which also deploys services with Bosch. So, how is it different? Yeah, so the on demand service broker API is a specification for the front part of it, the REST API that the platform will call the broker using. So, behind the REST API, you can implement a service broker however you want. You can have one that just like pipes lines into a text file if you really want to. Say, here's my service instance, a text file. I don't recommend doing that though. Not very secure. The on demand service broker does implement OSBAPI. So, OSBAPI is just like a set of rules, right? So, any service broker that complies to OSBAPI in theory should plug and play on any platform that also is OSBAPI compliant. The on demand broker is an example of one of those brokers. Any other jokes? Great, I think that's it then. Thank you so much. Thank you for coming. I really appreciate it.