 You guys are awesome. Thanks for coming. I'm going to start with a demo because I could go through some slides and try to build up a story, and then you might think I'm one of the types of people who doesn't do demos. And I'm also going to take questions, and so the sooner you ask a question, the sooner the next person will ask a question. Because the next person will know, oh, this is one of those talks where I can ask questions. In fact, you've got like 30 seconds more to ask the first question. Do you have a question? No. Anyone? Well, at least you've spoken. All right, this is you're allowed to interact. If you have anything you want to ask or whatever, we can definitely interact for the sake of the people on Vimeo, because obviously not YouTube. I don't broadcast YouTube. And I'll try to replay, but I do want to start with a little introduction through the means of I want to show you something. The context here is that you're on Kubernetes. And the great thing about Kubernetes you've been told is you can do anything. I am going to assert that you shouldn't do anything. And there is this week corollary I make at the end where I'm not sure whether you should be on Kubernetes, but you have a reason to be there. But I do want to talk about whether you should be doing all the things. And so here is an app. I'm using Knative to do the deployment because it's a lot more fun than showing you YAML. So here is an app. And if I interact with this app, rather than setting up routing, I'm just sort of going through its load balancing IP and then sort of telling it what host to go through. And it says, hey, I need a URI. I'm an app that wants to talk to a database. You haven't given it to me. I can't do what I need to do. If only all apps failed so nicely. And so let's redeploy this with that URI environment variable, just like Cloud Foundry, Kubernetes environment variables are one of the nice ways to express what you want to pass through configuration. So we could just pass in an explicit environment variable given to us on a post-it note here as your database. And that's not really ideal because now it's in plain text. So what you might want to use is secrets. Now, again, whilst I'm doing a Knative command, Knative is just mapping down to pods and all those pod structure things. So you'll see. So I'm going to set up a URI. And I'm going to, this value is going to come from a secret, which I've already set up, which is the premise of the talk. So we'll come back to it later on. Having done that, I've now forgotten what the secret is called. It's called MySQL via Cloud Foundry. That does somewhat give away what's going on here. And I happen to know that there is a bit like a Cloud Foundry credential. When you look inside the credentials, you might have host and port and things like that. There might also be URI one. So I'm just going to take that one because I know I've got it. We're going to redeploy these pods with this new secret. And so now when I look in the pod, it's still a secret. It still doesn't say what the value is. If I put it inside the pod, I will have my value. So now I have my value. And what's interesting about this value is that it's a clear DB URI. It's my Kubernetes cluster running in Google Cloud in Australia. And so hooray for the internet. Also, I don't know anyone at clear DB. I don't know if they support Kubernetes interconnectivity. And I have not had, in doing this, had to set up any formal payment system that I hadn't already have. I do not have this. So I did this via Cloud Foundry, specifically Pivotal Web Service. I did not have to set up any new credentials or payments that I didn't already have. I didn't need to have admin to Pivotal Web Services. So it's lucky because I don't have it. Just in case you're wondering whether I needed it and do have it, I don't. It would be awesome. I don't. And I was able to do all this with some of the things we're going to talk about. And so this app doesn't actually talk to that database. And obviously networking would need to work. But I know in this context that that database is public. As long as you've got that full URI, which by the end of this talk, and for the people on YouTube, will no longer work. So don't worry too much about writing down the URI. It's a tiny little MySQL database. And this is the context of what we're going to talk about. This idea of your Kubernetes cluster not running its own MySQL database, but deferring that to people who do want to run MySQL databases. So we're going to talk about the service catalog that's in Kubernetes. And we're going to talk about one of your options since your Cloud Foundry people are deferring, just delegating the whole thing off to your local Cloud Foundry. So if you're a Pivotal Cloud Foundry, you've got tiles. You've already got all these tiles with all these services. When you use PKS, you could use these ideas just to go off and get those services. If you're a public cloud, you could use someone's Cloud Foundry, get email from SendGrid, et cetera, et cetera. All right. So separation concerns. So now even if the last part of that, talking to Cloud Foundry is not interesting, I do want to talk about service catalog, and I do want to talk about separation concerns. I am concerned that one of the reasons people like Kubernetes is all the wrong reasons. Because one of the reasons people want to use a little bit of Kubernetes is because there's one or two things they just cannot do on a thing like Cloud Foundry. And if you say that with the right tone of voice, you might think you're right for having said it. It's like, oh, well, I can't put a WordPress app on because I don't have state. That's a pretty slippery slope to Helm install MySQL, apt-get install MySQL. These are the tyranny of letting developers do what they want. And if you've never looked, if you go to the MySQL home chart and look and read me for it, it doesn't mention the word backup once. So what's the chance if you let your developers, I mean, go through the math of this, if you let your developers install MySQL any time they like, what's the chance that they all have backup set up, that they all know how to do recovery, that they go through a runbook of how to do it and practice it and know how to make the executive decision of when to do it, recovery versus when to just wait for the thing to come back in. What's the chance of them? I mean, it's a very low chance. And one of the things I like so much about Cloud Foundry is, as an experience, it sort of separates out these separation concerns. It says, you can ask for these things, and they will come to you fully formed and working and managed by someone else. And so I really dearly wish people who go to use Kubernetes still bring that into their life. And the way we can do that, and I'm not the only one, I borrowed some Kelty Hightower who is both the person responsible for everyone using Kubernetes. And like anyone who sort of advertises something, that news spreads really quickly. He's going to spend the rest of his life now telling people not use it for all the reasons that they thought they wanted to use it. So can I run staple workloads? Perhaps they shouldn't. Some people believe that rubbing Kubernetes on a staple workload turns it into a fully managed database offering. This is false. In your organization, if you have a small team, definitely don't run your own databases. If you have a large team, don't run your own databases. There's a quick summary of my talk. Sorry if you'd like to... Oops, can't make the love of all things precious. There we go, if you'd like a photo of. We're good. I'll put the slides on speaker deck. And so I want to introduce a Kubernetes concept called the Service Catalog. I will not be talking about the concept of operators, but as another way, but I'm not sure as whether or not that is people respecting that premise of separation of concerns, or it's just another way to spin up my SQL. Service Catalog is an idea that they borrowed. They borrowed our API from Cloud Foundry. We made it there, an open shared API. It's been great because they have, their motivations been iterating it forward. It also means there are some implementations of service brokers for whatever public cloud you might be on. So from in this experience, you can go and get an Amazon RDS database. As easy as if you could go and help install my SQL. Hopefully, easy enough that you will do the right thing and not do the help install things. If you're help installing something, I'm not sure exactly what the scenarios are, where that's going to all work out well for you, but it is a question of whether you should go and get a service from somewhere else. And so the separation of concerns with this idea, you get the idea of provisioning and binding. It's a very simple experience. There are things missing, like, but we, sorry, the provision and bind, you unbind, you can unprovision and delete the thing. But it's a very simple pattern that we've had in Cloud Foundry for the last six, seven years. And this is what the service catalog brings to Kubernetes. And so I want to care a lot about this idea, and the corollary of this is I built that broker that I demonstrated that goes off to a Cloud Foundry and lets you have access to this marketplace. So there's a couple of different takeaways. One, you've got Kubernetes. Investigate the service catalog idea. Find some brokers that give access. Separate your teams out. Someone has to be responsible for databases, and it can't just be the developers. And possibly defer to other organizations and look at the service broker idea as how to formally separate those concerns. And then if you've got Cloud Foundry, you've already got this, and we have a solution for you. So the service broker concepts. I sort of started them. There's a marketplace of services. And this is where it's a conversation between developers and the organization around what are we all okay with using? Yes, you read a blog post once about Mongo, and now you want to use it. But you probably didn't read the blog post about all the terrible things that happened to people that don't set Mongo up correctly. Like, it doesn't store state by default. I mean, I know it says it's a database, but you'd think it would, but it doesn't. It's just not one of those things. So you're going to have your ideas, and the idea of a marketplace allows there to be a current set of things the organization's happy to look after. And if you want more, have a formal conversation of what else we'd like to do. We'd like Kafka. Great, let's try Kafka out. Let's see if we want to support it. Do we need to get a vendor to look after it? Do we need a little offsite or whatever? And then you can provision-de-provision, which, if you're wondering, is good. Well, just go off and send a JIRA ticket to someone, just to remind yourself of what it used to look like when you wanted something. It's a complex experience about asking for things and getting them in seconds or minutes. And the service catalog both comes with a CLI that feels similar to the CF command, or you can use the custom resource definitions that's sort of the underpinning of how Kubernetes is pretty cool. So this is perhaps a bit of a flow diagram. You'll see in the middle, if you've seen the service broker and service instance ideas, but I'm going to show you some examples today, and that is CLI talking to the service catalog as an API that we're going to send requests to, just sort of like the Cloud Foundry, Cloud Controller, and it will send out to request to a service broker, which might be running on the same Kubernetes cluster, or it might not. It's just HTTP. You don't care. You just care that eventually you get a service instance that works for the next decade or two. And that service broker might go off to a cloud and ask for infrastructure. It might just be a fully formed thing. It might cut up a shared database. The definition of what a service broker can do is entirely up to the author. If your organization has split itself up as per my previous slide and they're writing their own service broker, that's part of the conversation of what services or what plans, which way you want to provide that to the developers. You might want tiny plans. You might want big, hunking, multi-BM things with failover. The broker will then configure the service instance, and over time, your pods will now have access to that. Through that idea I showed before of using secrets. So in Cloud Foundry, we have bindings with the credentials and the VCAP services. In Kubernetes, we have secrets. They're not very secret secrets, but they have the right name. And that's important. You get at least the terminology right. All right, I'm not going to install it. This is just for your future reference, but it is essentially installed as a Helm chart. And there's different ways to get the CLI, but the CLI is this SV cat. And obviously this assumes that you've already got Kubernetes. Everyone assumes you've already got Kubernetes. No one wants to talk about where it comes from. The birds and the bees story of Kubernetes is not to be discussed. Whereas with Cloud Foundry, we talk about Bash, and we're proud of it. Everyone's magically assumes Kubernetes already exists. I don't want to break that story. It magically exists. Now we're going to magically install service catalog onto it. And then we're going to use it. So obviously, I've already registered a broker. And I will show you that cool broker. But any broker, we have in our Cloud Foundry universe lots of demo brokers, simple ones, big ones, open source ones, proprietary ones. And if you're pivotal, you've got the tiles, all of those are brokers. This idea is it all holds. You've already got that broker running, and you could register it like this. And then we have our marketplace. So let's have a look at our marketplace. So just to remind you that, oh, I know you probably can't read the font, but I just thought, oh, it still looks terrible. It's these people with their ridiculous number of plans. It's their fault. I hate that. Oh, plus now it's a little. I'll try not to spend too much time looking if the font's a little hard to read. I apologize. So we have many plans. And this is me looking at my Cloud Foundry. And just so you remember, that's a Cloud Foundry service. And you as a member of this, you know, that organization can pick and choose from these. Some might be free. Some might your team might have to pay for, depending on how you will do that internally. And then if we look at the CF Cat Marketplace idea, it is exactly the same thing, just formatted differently. Arguably nicer in the sense of it doesn't overlap and overflow everywhere. But that's, if that's what you're excited by, then you can go now because that's, I feel like I've given you everything I've got. So there's a set of plans. Now, again, like we know where I'm going. This is all pointing to the same Cloud Foundry. But to go back to just talking about service catalogs, you will have registered your broker on each of your different Kubernetes clusters, okay? So it's certainly my confident belief that you're probably going to have multiple clusters in your environment amongst your teams for isolation. So you're going to go through this process for each one. Install the service catalog, set up your brokers. And so now we've got, we've got email. Look at that. I didn't have to go and ask anyone to set up a relationship with Sengrid, which is, I've got, I've got an email system. And so where was that ClearDB? All right. So we look at ClearDB. Unfortunately, it doesn't really print out to say what these all do. I just happen to know that Spark is the cheap one. And then they get more expensive. So let's use the free one. All right. So we have the svcat command. And look, it looks very similar like a subset of the CF command set. The focusing around brokers and service instances. So svcat, we're going to provision a thing. And I'm going to cheat and just move ahead. And I'm going to move that up the screen so you can see it. And I'm going to make the font bigger because I love you. And so it's a command. And it's very similar. They've got a slightly different terminology that we have. In Cloud Foundry, we would call it a service and a plan. They've got my class and a plan. But it has a name. And you'd run it. And then there's another command for svbind. And use the name. And what that does is generates a secret. So it goes off to the broker to provision. And when that finishes, it comes back. When then you go and ask for binding. Bindings are your attempt to get a unique set of credentials. Optional to the broker. If that means nothing to the broker, like if you're doing Redis. Redis doesn't have a great user password model. Just will give you a password. And if you bind again, it will give you the same password. Like whatever. It's not your fault. But you do get a set of credentials. So a binding is where it is. And how do I find it? And who am I when I talk to it? And what you end up with, because I've already done this. And I apologize. And I will. We're going to come back to it. As you end up with secrets. All right. And there's our secret there. All right. We talked about the marketplace where I printed it out pretty because it was really ugly. And so now we're going to talk about this idea of a specific broker that you might like to use if you've already got a Cloud Foundry. Okay. Either we public cluster and talk to your PKS or a BlueMix or whatever. Or if you're on-prem and if you're a PKS user, you can install PKS. Even if you don't install any Diego cells, you can just run the Cloud Foundry and all the brokers, all the tiles, just so you could then use them in PKS. And this is the basic model. We're going to run the broker. We're going to run that broker in your Kubernetes cluster. Not important. It's stateless. It's just passing. It's just a route. It's just proxy and traffic. But we will put it in our cluster. We're going to talk to our CF API. And then it will go off and do whatever it does. I didn't write any of those brokers. I didn't write the clearDB one. Works a treat, but I didn't write it. And so here is a different way. Let's do it with SendGrid. The request comes through that SVcat provision request. We don't. The broker that I'm going to talk about doesn't actually run a CF command. That's childish. But it does. I mean, it's probably worked really well, but I didn't do it. It sends the equivalent API request across to the target cloud boundary, which in this case is api.run.pivotal. And that then goes off and does its thing to whatever broker that goes to. I mean, to be fair, a bit of an implementation detail doesn't actually go off to a SendGrid broker. They have a partner called AppDirect. I think all of them go off to there and they go off. They have their own proxy. It goes off and does things. But in the end, what I get is a set of credentials to an email service. And now my Kubernetes app can start sending emails. All the payment for it and everything is all managed through my cloud boundary account. And I didn't need to have any sort of thing going on in my Kubernetes. So installing this. Again, not expecting you to type this down, but for completion. And it's in the readme. But essentially, you're going to pass through someone's user credentials. The person whose organization is going to pay for the thing. And the current implementation is specific. All the service instances are stored in one space. You might not like that. Great. I appreciate you caring. And we can look at what else we can do. But right now, for the first version, if you create lots of different service instances, they'll all go in the one space. Anyway, because it's all implementation detail. So that runs. And that's our broker. And then I mentioned that the next thing, once you're running a broker, whether it's running on that Kubernetes cluster, running somewhere else, it's just HTTP traffic, then you register it. Similar to if you're a cloud boundary operator, you would have registered brokers before. You are now a Kubernetes operator. And you get to register brokers. And boof, up it comes. It is other than typing out those long things, it is that simple. And now we get our marketplace. All right. So let's, how are we going for time? So these are the commands where you can play. I mean, so what's interesting about Kubernetes, even though you've got that SCCAT experience, it is just creating Kubernetes CRDs. And so then you can go and look at them. So there's one called service instances. Another one called service bindings. This is what are being created. And they're constantly trying to wait for something to turn up. And so I will run this quickly, so you can sort of appreciate. Give it a different name. And then we'll also quickly, SCCAT bind. And what's interesting in a difference from cloud boundaries, you can go straight into creating the binding, even though the other thing hasn't finished yet, because it'll just keep waiting until it can. So if you look at services, I'm already logged into the space where these are going. And so it's now created. It's one of these two. That's pretty bad. I don't know which one it is. And the way that I've implemented it for your interest is with service keys. So it would be the worst if it doesn't work. All right. So there's a service key. And so if we now go and look at our service key, so this is purely implementation details for people vaguely amused by how this might be implemented, you can see that there is the binding. Now, this is all behind the scenes. The users of your Kubernetes cluster don't necessarily have access to this. But it might be you, in which case you do. But on the other side, on the flip side, we have our get secrets. And we called it, we called it, what did we call it? Where did it go? How did I screw that up? Because it didn't look like the bindings were working, did it? How do you exist? This is exciting. I don't really want to debug something. Error instance, not ready. Something's gone wrong. And I apologize. But you can start to see that the other one works a treat. So let's look at the other one. Kubernetes get secret. And there is what the secret looks like inside Kubernetes. And again, as a user of Kubernetes, hopefully you don't find yourself doing this all day long. What you ultimately want to do is that at nvsecret command. So now we're going to redeploy our app where we're going to reference that secret. So it was a service instance. It became a binding, which a binding maps to a secret. And we're going to select out the slash URI attribute, which is this one here. And when I joked before, I said they're not really all that secret. They're just base64 encoded. So if you want to find out what is a secret, decode it. And if you don't know how to decode a secret, then it's such a secret. Or you could use Google and find out. Yes, I did this before. And it will work as effectively well. I did mention, so there it is, the passing through that secret. And I did mention that get pods, I forget, spec containers, something like that. Oh, that was quite a guess. Maybe it was a bad guess. Here we go. And so again, in this case, I'm using Knative. But it's just using, this is the Kubernetes way of doing, setting up an environment variable where the value of that will be deferred until runtime from, in this case, a secret, which we know got populated by our service catalog binding. It's really interesting. And if you're going to be a Kubernetes user, if it's one thing I would ask you to bring from Cloud Foundry is this idea of service catalogs. All right, let's finish up. We did bindings. I showed you that internally the way that this is working is just mapping to service keys. And we looked at the secrets. And that last thing is just me showing off. Look at how I can pipe things together. And there's, damn it, I showed you how to break the secret of the base 64 decoding. So we went through this example. And again, it wasn't actually directly to a ClearDB broker. It was to the app director. That's just an implementation detail. But on your Cloud Foundry, you will have brokers. And all we're doing is calling out to those. And it means that if you need to, so for the, and I haven't integrated this into the tool at this point, but it does allow you to do the debugging. And it gives a good example. I want to show you a good example of why you want to defer to other people to run these things. And that is if we, that service doesn't exist, there is a CF plugin for, so there is a CF plugin called Open. And it has two commands. One is open an app. And the other one is open a service. And this allows you to get the dashboard URL for the service, pop it up into a browser. And then we can log in. And so ClearDB has a dashboard where I can now see all my cool things. None of which is available with the HelmChart. OK, so this is another reason why it's great to defer to other organizations who are going to provide you a service. All righty. Finishing up like champions. There's our marketplace. Not everything you find in Cloud Foundry is going to be meaningful in your Kubernetes cluster. The scheduler for PCF triggers Cloud Foundry containers to run not so useful over in your Kubernetes. And I'm guessing the app autoscaler is pretty specific to Cloud Foundry too. All right, just to go back, and I just want to finish up now. So I want to miss out on, you know, now that we've shown you everything, I want you to know why. I truly believe the value that Cloud Foundry brings is in part the separation of concerns. Perhaps it's also the thing people rebel against because they can't do a thing they want to do right now. It is not an excuse to just abandon everything because you want to install Mongo really badly. Use Postgres, it's got JSON support. You tell me why you want to use a thing and I'll find you a thing you can use. And the idea of separation concerns might add... If you can make it as easy to do the right thing as to do the wrong thing, ideally your organization will behave well. It's going to be hard to stop people using Helm, but hopefully it's easy for them to use the services your organization is happy with. And similarly, the service catalog is incubator project within Kubernetes. Please have a look at it. And if you're interested in this CF marketplace broker, you can find that there. And it works as advertised most of the time. Thank you very much. And I believe we have time for questions. I believe that the same way that your president believes things and that's without facts. Where does the... Okay, so the question was where does SVcat run the CLI? The CLI was running on my laptop. It's optional because it's essentially just creating the CDRs. It's creating the records in Kubernetes. So when you run SVcat, when I run on my laptop, SVcat provision or SVcat bind, what's being created is, I think, almost literally all it does is creates the service instance CDR or the service binding CDR. CRD. CRD. I've said the wrong thing the entire time. You fix that in post-production. And make me look better. So SVcat is just a CLI like the CF CLI. Service catalog is an API like the Cloud Controller is an API. And the service catalog is running wherever you want, but in our case we ran it on our Kubernetes cluster. No, it has to run on your Kubernetes cluster because that's what registers the CRDs. Nailed it. The next group is going to love this talk after a minute. Yeah. And have a secret. If your app running in Kubernetes is able to access that database... The assumption is that it can reach it. The assumption is that networking-wise it will be able to reach it. From SAP about doing some Istio magic in the case where both your Kubernetes and your service might be running each behind-network-addressed translation things. Have you encountered that kind of situation? I wouldn't want to put myself in a situation, but no. I would imagine that is part of the... That might be a problem. And in which case this might not... This is not offering any proxying solutions. This is... If you've got this particular set of problems and networking is not your problem, this will work. Sorry. I'm not going to solve networking. It's awful. But yeah, this conference has had a number of attempts to solve this merging of these two universes. One was a Rini where let's just bring Cloud Foundry to the Kubernetes and now we solve networking. The other one was the service fabric. I wish they had done it in a smaller audience where I could have asked more questions. And then there was the demo of bringing Silk to... The keynote this morning, Bill did the talk about bringing Silk to Kubernetes so that they had the same networking. Therefore you have a way of sharing. It's good to have options. And then this one, again, the broker in the essence essentially went off to another place which registered something on a completely different network. It just happened to be public and it could be shared anywhere. Okay, so the question is, can it pass JSON config? What it's doing, I believe, yes. I mean, all it's doing is passing whatever came back from the credentials. So when your broker, the open service broker API has like five to six or seven end points and one of them is provision or create service. Another one is bind or create binding. And you get to return, a binding get to return a JSON object with credentials. And that can be nested, so you can have an object that has objects there. And that will just be passed through. So that will be stored in Cloud Foundry as a service key and then it will be passed as a nested. So it then becomes a question of what Kubernetes does with that secret. When one of the keys is a JSON object itself, I trust it will just be a string and your app will just have to pass that. I can't see an issue. I took the opportunity to explain it all again one more time but I don't think there's an issue. Oh, sorry, is that the question? Sorry. Let me demonstrate so that now that I know what you're talking about for everyone else. So in provision, we have some prams, JSONs, those sorts of things. So if my broker does not pass them through, I apologize and we'll fix it. There is, okay, this is where there's a little bit of a hiccup with how much I can do. It's because I'm using service keys. They are slightly second-class citizen in Cloud Foundry relative to bindings and they are a little bit lost in the transition to V3 API. So I know at least one thing I can't do with service keys that I can do as a binding that I can't get fixed because we'll fix it when we do V3. But nonetheless, it's all open source so if anyone else actually finds that bug, I sort of just figured it out, then we'll worry about it. We can fix it in CF or we can, you know, but it's not really that important until someone finds it. I dare you to find my bug. Asynchronous, it should. Service keys, well done. You found my bug. Yeah, that was it. I thought if I forgot the bug, it might go away. So here's the repo and we can do update. Yeah, there you go. Support asynchronous brokers, which is what you said. But yeah, if it's really important, then we'll go on. But bindings, I don't know how many binding operations truly need to be asynchronous. And you can always readjust the broker directly. So instead of this, you can just readjust the broker. I don't know, yeah, that sounds good. All right, everyone, thank you very much.