 Hello, welcome to the third video on building and running microservices in OpenShift. In the last two videos, we talked about how application components run on OpenShift, how they are made up of pods, services, and routes coming together. In the second video, we covered how microservices run on OpenShift and what the microservices are made up of and how OpenShift supports as a platform for microservices. In this video, we will look at developer standpoint on how to create microservices on OpenShift as a platform. In the next video, we will cover from the deployment standpoint. Our example has three different microservices. The first one is an email service, and this will be used by the actual application. It's written in Python. This is a polyglot setup. Each service is written in its own language. The email service runs in its own pod. It has its own service, and you could expose email by using a URL, or you can use, if the client is internal, you can just use the local RESTful interface to talk to the email service directly. We also plan to introduce MySQL database to store the email logs, but this part is not built yet. It's still working progress. The next service is a combination of two services that come together. These are two different microservices. First, let's look at the right side. This is a user registration service. This is a simple user registration part where a user would come and self-register oneself, providing their personal details, and the pod will receive those details, and it will write into a MongoDB database. The MongoDB is a separate pod where the data is written into. In this case, this is like a multi-tiered architecture where there is a database as one tier, and there is a business logic in another layer which exposes a RESTful interface using which you can register users, get the list of users, and things like that. This also has a required interface for email service. The other service we talked about in the previous slide, when the user gets registered, it sends out an email that the job is done. So email service is generic. It doesn't care what kind of email it is sending. As long as it knows that it has to send an email to this address, it will just go ahead and send it. So email service could be used by other services as well. So each microservice is doing just one job, and each microservice is written in a different language. For example, the email service was in Python. This guy is in Node.js and using a MongoDB. On the left side, you'll see another microservice, and this microservice is a PHP client, and this PHP is producing plain old HTML pages that get back to the browser, and from the browser you would be making Ajax calls to the user registration microservice. So the job of this microservice is just to produce that UI that is required to show the application, the HTML. So how do these all come together? So you have the browser, which is the client, the user goes to the browser and accesses the user registration microservice. This has PHP running in it, and it produces the HTML pages that get displayed in the browser. The user fills in the details and then says, I want to register. At that point of time, the browser makes Ajax calls to the user registration API microservice. This is the backend, and this guy goes and registers the user and saves the user details in the user database, and then it can also give back the list of users available if the browser asks for it. At the same time, when the user gets registered, it will also send out an email by making a call to this email microservice. This is a completely independent microservice running separately. As I said before, the email log part is yet to be built. This is a very simple example where three microservices are coming together. The code is available in the Git repository. This code is built by my colleague. His name is Chakri. When you look at the code, there are three microservices here. One is the Node.js user registration backend service. There is a UI front-end for user registration, which is the PHP application, and there is a Python application that does email API. So three different microservices. If you look at the readme, it will also talk to you about how to create these microservices in your OpenShift environment. First, I'll create a project to deploy these microservices to. I'll call it MSDev to represent microservices development. I'll say create. Now that the project is created, and for now I'll use command line. First, I'll export a couple of environment variables. I've logged in. I'm changing into the project. So I'm using the microservices development project. Now I want to create that email service. This is the same service that we discussed before. This is the first service that we are going to deploy. This part is not built yet. The code only has the email service. I'm pointing to the Git repository that I showed you before. We are selecting that particular context directory, which is Python email API. This has the code for the email service. I'm naming this application as email service, and then I'm choosing Python 2.7 as the image stream to use. This is the Docker image that it will be using, and I'm also adding a label to this application that says the name of this microservice is so and so. You'll see why I'm doing that later. This ends up creating an image stream, build configuration, deployment configuration service, and all that. Now if you look at the web console, it has started a build for the email service. This build will run for some time, and it will deploy the email service part. Note that we have not created any route for this application. We are just going to use this email service as an internal service, and it doesn't require a route. We are not going to use a route in this case. Next, let us deploy the user registration microservice, and this is the backend service that does the user registration. It has two parts, the MongoDB database, and it has user registration service itself, which is written in Node.js. We'll deploy these two parts next. Note that the user registration service has a dependency on the email service, so we need to tell this guy on where this email service is running. Now we are deploying a MongoDB. I'm just pointing to the MongoDB image to deploy, and I'm also passing some parameters, which is the username, password, the MongoDB database name that it has to create, the passwords to use, and all that. And then I'm naming this application component as MongoDB. I'm also labeling this as user registration service. So everything in this service, we will call it user registration service. Now this guy has created an image stream for MongoDB, a deployment configuration for MongoDB, and a service for MongoDB, and it will end up deploying a MongoDB service in the same project. Now the MongoDB is now deployed. There is one instance of MongoDB running, and there is a service that is front-ending the MongoDB. And if you look at the labels, it shows that for this service, the label that we assigned is here. Next, we will deploy this button, which is the Node.js code that can do the user registration. So I am now deploying from the same Git repository, a different context directory. This thing is the Node.js application that does user registration. I'm giving it a name, user registration service, and I'm assigning it the same label, user registration service. And the same label was assigned to the MongoDB part as well. So both are being tagged as microservice equal to user registration service. Now I'm also passing some parameters here, which allows this service to connect to the MongoDB database. The MongoDB database name, password, user name, and all that stuff, which are required to talk to the MongoDB. And the way in which this gets connected to the MongoDB is by using this database service name called MongoDB. In addition to that, we know that this part of the application has a dependency on the email microservice. So the email microservice service name is what I'm passing here. So this email service colon port 8080 is that this is the services name. OpenShift will resolve this service name into the IP address of that service internally by using this IDNS. So now this has created the build configuration for user registration service, and it will pull the code from this Git repository from this particular context site, and it will deploy that as the user registration service part, and then it will frontend with this user registration service. Now if I look at the services that are running in this project, there should be three of them. One is the email service, the second one is MongoDB, and the third one is this user registration service. Since this service is going to be accessed using RESTful APIs, we will expose this service. The service is exposed with a route. Now you should see the route for this service. So OpenShift has assigned this route name to the service. When you are creating an application as a developer, you are building the application with each of these individual pieces, and you are putting them together. Now let's see what's going on in the web console. The email service is now built and deployed successfully. The MongoDB is running, and the user registration service that we just created, the build is running on this guy. So it will download that Node.js code, build the code, and deploy that as a part. This service also has the same label, microservices, user registration service, and MongoDB also has the same label, microservices, user registration service. Now the reason why we are doing it is to say that these two are part of the same microservice. We are going to group them together later. Next, we are going to deploy this front-end microservice. This is PHP code that generates HTML. So in this case, again, we are going back to the same Git repository, and we are going to that PHP user interface code, and we are deploying that as an application. In this case, I'm labeling it as front-end microservice, and I'm calling this as user-rich, used for user registration. This particular application would have to link to the other back-end service, right? So we are providing an environment variable that connects to that back-end service. By default, when you created the route, the route would have the application components name followed by the project's name, followed by the domain name. OpenShift names the routes by default. So that's the reason why we exported these variables earlier, so that it's easy for us not to type all these values here. It's just for the sake of convenience. So now I'm deploying the service. The front-end service is now getting deployed. If you look at services again, you would have a service for this front-end service as well. Since we want to use this front-end service from the browser, you would need to expose this as a route. So let's expose the service. Now, if we look at the routes, there are two routes. One is the route for accessing the PHP application and the other one is the back-end service that exposes RESTful APIs. We need both of them. And this is the one that we configured for the front-end to use. So far, we have deployed the email service. We deployed this entire microservice in two pieces, the MongoDB and the user registration service. And for the user registration service, we said that it would have to talk to the email. So we provided the service name for the email service. And then we deployed the microservice for the front-end part and we exposed the route to this guy. The front-end application is now being built. It will take a couple of minutes for it to get built and deployed. So let's give it a moment. We can see that the user registration service is now built and deployed. It also has a route. So let's click on this route and the screen came up. So this is the registration page. I register myself, say, and I'm saying register now. It says registration is successful. And I can just add one more user. So I added two users and let me log in just using this microservice, right? So this guy inside login, get the list of friends and this friends list shows the two users that I did. So it's microservice. It generated this UI. Let me show you the source. If I look at the page source, it has some forms using which I filled it. And it's going back to the script. The script is actually making a call to the back-end service and this back-end service is nothing but this service. It's making restful calls to add the users and also get the users list as simple as that. Very simple, silly set of microservices. I also received an email that the signup is complete. So in this example, we saw how a developer uses OpenShift as a platform to deploy microservices. So we saw how we can create an application to deploy the email service. And then we deployed the second microservice which included both these components and we labeled them as the same, right? And we have deployed each one individually. And then we also saw how to deploy the front-end microservice separately. So there are different microservices here that were deployed at different points of time. Now the developer can make changes to these microservices and rebuild and redeploy into this development project as many number of times as the developer wants. So this is the development platform for microservices. In the next video, we'll see how to take these microservices that are deployed as individual features, package them together and move them into production as a group.