 The last video was an introduction to service broker in this video will learn how service poker works on the OpenShift container platform. The first concept is a service catalog. It provides a single integration point for different service providers across different platforms. It also provides a consistent experience, whichever service you want to spin up the applications deployed on OpenShift running as containers can connect via the service brokers to different services running across this platforms in the same way. So, you don't have to think about, hey, how do I connect to AWS versus Azure? You get a single interface via service catalog and hence consistent experience. On an OpenShift cluster, you can find the service catalog in Cube service catalog project. The parts that you're seeing right now are the ones that represent the service catalog. Service catalog is accessed by the client. The client could be user interface or CLI. Log onto an OpenShift cluster. The first thing you see is a service catalog. On the web console, you're able to discover the services and instantiate the services to use with the applications running on OpenShift. The next concept is service broker. This is called cluster service broker on OpenShift. This is a server that corresponds to open service broker API specification. Now, you can run service broker on OpenShift or outside OpenShift. On your OpenShift cluster, you can run OC get cluster service broker to find the service brokers running on OpenShift. In my case, I'm running three different service brokers. One is a template service broker. The other is Ansible service broker. These get deployed when you install OpenShift and I also deployed AWS service broker. And this reason why you are seeing the AWS related services on my catalog. So there are different types of implementations of service brokers which could run on or outside OpenShift. There is a template service broker that comes along with OpenShift. This will provision or OpenShift templates. There is an Ansible service broker and this allows you to create your own Ansible playbooks that can be used to instantiate services either on OpenShift or outside OpenShift. Then there is AWS service broker. This is provided by AWS. This is to spin up AWS services. In the same way, service broker for Azure is being implemented by Microsoft. This can spin up services on Azure. So you can have different kinds of service broker implementations. You can implement one of your own and forming to the OSP API specification. The actual service is represented as a service class. The service broker manages this service class. It's one of managed services offered by cluster service broker. The service catalog controller inquires a service broker to find all the offerings made by each service broker and it creates cluster services classes that are made available by the service catalog. The cluster service classes are shown on the service catalog when you view it through the GUI or you can also list them using the CLI. Service classes are of different types. You can have different service plans. For example, you can have development versus production or gold, silver and bronze kind of plans that might represent the quality of service that the service class provides. You can get a list of cluster service classes that are managed by these cluster service brokers by running the command oc get cluster service class. I have a bunch of cluster service classes that are offered by these three different service brokers. Now let's look at a cluster service class. You can see that this cluster service class is managed by Ansible service broker and it spins up a PostgreSQL database. The next concept is a service instance, which is the instantiation of the actual service. So service instance is an instantiation of service class. The service instance itself runs on the service provider, whereas the service class is listed in the service catalog. The user wants to create a service instance. The service catalog controller instructs the cluster service broker to provision the service instance. Provisioning is a process of creating a service instance based on the service class. The credentials that are required by your application to connect to your service instance can also be created at the time of creating a service instance. Next, in order to link your service instance to your application, you would create a service binding. So when the user chooses to do that, the service catalog controller creates a Kubernetes secret with the connection details and you can choose to add that secret to your application so that your application can talk to your service. And if you are no longer using the service, you'll remove the service binding and you can deprovision the service instance. The service stops running. And all this is done via the OpenShift interface. So in this video, we have learned how service broker works on OpenShift. The concepts of service catalog, the service broker, the service class, service instance and service binding. I hope you enjoyed this video. Thanks for watching.