 Hello, welcome to the video series on using code ready workspaces and road launcher for cloud data application development. So let us begin by understanding this technologies. First, let's talk about code ready workspaces. Code ready workspaces is based on an open source project called Eclipse J. This is where you can take your developer workstation and run it as containers. What are the use cases for this? Let's say you want to accelerate the onboarding time for your developers, or you want to prevent inconsistencies such as, hey, it works on my machine. Why doesn't it work on yours? Or you want to protect your source code. You don't want the source code lying on a developer's workstation. These are the cases where the code ready workspaces apply. If you components make up the workstation, the first thing during these runtimes, you may have one or more than one runtime as part of a workspace projects that are mapped to source control, like a Git repo, are mounted on the top of these runtimes. Code ready workspaces also comes with a private browser based IDE, which comes through Eclipse J, that is typically hosted along inside the workspace. Now, in addition to the IDE and the runtime, you would have all the dependencies that are necessary to edit, build, run, and debug your application. When you put all these things together, the project files, the IDE, and the runtimes, that makes up your workspace. Entire code ready workspaces architecture becomes an application that's running on the top of OpenShift. Each workspace would be a part. These workspace parts are created and managed by a workspace server, which is also a part. For user management authentication, we would go through a key closed server. PostgreSQL database acts as a data store. And both the workspace server and the workspace itself are accessed by the end user via a browser based client. The workspace server handles workspace orchestration. And you can also create and manage stacks for different technologies. If you want to share your workspace setup, including all the command that you can do as part of a workspace with other team members, then you can create factories and share. You can do workspace administration tasks, such as setting up private registries. You can also create organizations and assign members. The key closed server will handle user management. Now that we understood how code ready workspaces are actually deployed and worked, I'll explain these code ready workspaces in the subsequent videos with practical examples. Let's move on to understand Fabricate Launcher. The Fabricate Launcher is a tool for a developer to start building Greenfield Cloud native applications. This is the tool that generates starter code, or you can use example code to begin with. It integrates with a Git repository, and your starter code can be copied into a Git repository. The launcher would also be able to deploy the code into an OpenShift cluster, or if you can download the generated code as ZIP file. The launch will be able to generate both single tier applications or multi tiered applications with a front end and a back end. We support technologies that are part of Red Hat OpenShift applications on times for cloud native application development. These include React, Angular, and VueJS for front end, and Spring Boot, Thontail, NodeJS, and Vertex for back end. So how does this all come together? Let's look at the workflow. Developer uses the launcher to generate the source code. This source code will be added to the source controller repository. At the same time, the launcher also applies that as an application on the OpenShift cluster that the launcher is configured to work with. Launcher also configures web hooks into the source controller repository so that any changes pushed into this repo will generate a trigger to rebuild the source code on the OpenShift cluster. We will go to the next step of importing the source code into code-ready workspaces to create a new workspace. This workspace would include the cloned source code from the source controller repository, an IDE, which is based on Eclipse J, and other configuration files. The developer will use this IDE to edit the code and build the code locally within the workspace, test it locally if required. Step-by-step debugging is also provided by the IDE. Once happy with the code changes, the developer will push this code changes into the repository, and that will trigger a new build and deployment of the newer version of the application into OpenShift. In the subsequent videos, I'll be showing you how this workflow comes together, so stay tuned. Thanks a lot for watching.