 Welcome to the video CDs on understanding service brokers on OpenShift. First, we'll understand why service brokers are required. If you think about a typical service provisioning process in an enterprise, it's usually manual and pretty time consuming. In general, a service consumer would raise a service request in a ticketing system. It goes for approvals and some administrator will provision the service on the service provider. You would receive the credentials and then the service consumer has to add those credentials to the application to connect that application to the service running on the service provider and then start the application. That's how it gets used depending on who the service provider is and the amount of manner process involved. It could be taking quite a long time to use it this way with cloud service providers by Amazon or Azure. This process is simplified a little bit, but it's still manual as a service consumer. If you are getting access to provision your own service, then the service provisioning process is probably simplified, but you still need to get the credentials and add it to your application, which which is still manual. In addition to that, the service provisioning process itself is different for each service provider. You would need to understand how to use each individual service provider. The user interfaces of these providers are different. Once you provision the service, you need to still tie it back to your application in different ways and use it. So this is all inconsistent manual and different for each service provider. Open service broker API was introduced for the same exact reason. It's a multi vendor project to standardize how services are consumed on cloud native platforms across different types of service providers. Service broker is an implementation of this open service broker API with service broker on OpenShift you get a service catalog where you will see services provided by different service providers like Amazon or Azure or even within your enterprise. You may have certain services that you would want to run and you can make them part of the service catalog. Now the service consumer would go to the service catalog, choose a service and instantiate that the service broker knows how to provision that service and it creates a service instance and makes it available for your application to use. Not just that your service broker can also bind that service that is just created to your application so that your application can start using it. So let's look at an example of what I just explained. What you're seeing now is a service catalog that is made available on the OpenShift container platform. As soon as you log in, you'll see the service catalog. There are different kinds of services here. Some of these are coming from Amazon. There is Amazon, EMR, Amazon Elastic Cash, Amazon S3. Now you also have different languages, different databases, different kinds of middleware, CI CD. All these are provided by Red Hat. So this catalog displays services that run on OpenShift cluster as well as outside the OpenShift cluster provided by an external service provider or your own enterprise specific services can also be made part of this catalog. Let us test using this service catalog. Let's browse the catalog. I'll try to provision a MySQL database. This instance of MySQL database uses a service broker. There are two types of database instances available here and these are categorized as two different plans. One is a development which has no persistent storage and the other is a production which requires persistent storage. For now, I'll choose development. I'll select a project into which this service needs to be deployed. I'll leave the service name as MySQL. I'll provide a password. Select Next. I don't have an application to bind this service. We'll do that later. So I'll just say create. Now it says the database is being provisioned and it takes it back to the project. The service is getting provisioned asynchronously. This will take a couple of minutes. So I'll take a pause and come back. Now the deployment is running and the database part is ready. That's how you provision a service using service catalog. Next we'll learn how to connect your database service to an application that needs to use a database for convenience. I have deployed an application that's already running here, but it is not connected to a database and I also have an instance of database that we deployed earlier. Now let's see how we can connect this database to the service. This application also has a URL. We'll try to test this database. This is a PHP application. It tries to connect to the database and the connection fails. Now we'll access this service. There is an instance running one part and will select this provisioned service to create a binding. The process creates a secret which contains all the credentials needed for your application to connect to this database service. It says binding is being created. Let's click on this and see and this is the secret that got created. Let's view the secret. It has all the connection parameters that are required for your application to connect to this database. Now let's add the secret to your application. So we'll bind this database to the application that wants to use it will select an application. Our application name is DB connect will select that. I want to add the secret as environment variables and save you'll see that the application is getting redeployed. There is a rolling deployment in progress. The application just got redeployed and the new instance of application is running. Let's also look at the deployment. If you look at the environment variables. There is a secret mapping that got added to this environment and this was added by the service broker. So I didn't have to connect the application to my database manually. The job is done by the service broker. Now, let's go back and test the application. Now reference the screen and here is the data coming from the database. Let's try to go and remove that secret from my deployment configuration. I'll remove this and save it. The app gets redeployed. So we have a new instance running without that secret. Let's test it again. There is connection failure again. You just saw how the service catalog provides the list of services that you can provision how the service broker provisions the service creates the binding with a secret that has all the connection information for your application to use and how the service broker adds their secret to your application's deployment descriptor so that your app can connect to the database and use it. In the next video, we will discuss how the service broker works in detail.