 Good morning, everyone, and welcome to Dev Nation Day India. Really happy to meet everyone here. And this will be a very interactive session, live game with you all, and telling you about a lot of interesting stuff, what we do at Red Hat Developer Tools. So let's start with it. And as you can see on the board, the main agenda of this entire session is to run through across multiple scenarios, across ID extensions, and the new product which is coming by Red Hat known as Red Hat Developer Hub. So we'll have a good demo around it, and feel free to have any questions during the sessions and even after my session. My name is Mohit Suman. I am based out of Bangalore. I work as a senior product manager, managing the developer experience at Red Hat. You can reach out to me at LinkedIn Twitter. So what is the main agenda of having a developer experience, right? The productivity of any developer is around multiple factors. So we have noted down across two scenarios how it improves a developer happiness and eventually improves its productivity. The first important stuff is how you can reduce your cost with respect to multiple infrastructures, right? If you see in today's current scenario, there are multiple workflows, multiple infrastructure a developer has to get started with, right? In previous days, oh, I'm a Java developer. I'm good with it. Done. But in 2023 and the future, you need to know multiple scenarios. I'm a Java developer. I want to deploy my apps on cloud. Oh, how to run it on multiple scenarios in Docker, containers. Oh, now I have to learn open AI. Do I need to learn generative AI? Multiple stuffs, right? So these type of scenarios always are there for a developer and they have to understand that how this is going to improve their revenues. When I say revenue, a faster developer productivity is eventually going to increase the revenue of your company, right? This is how developer happiness is going to impact, both on cost and both on your faster development. And this is how Red Hat Developer Tools is going to help onboard and get started with it. So when we talk to a customer, right, let's say I'm a company and I want to develop some applications and I want to talk to a customer, right? The best part of that is a developer tool will help you to make that scenario fulfilled, right? It will help you to be productive. It will help your applications to be deployed in a productive fashion. But these all are scenarios which looks good on paper, right? But how do we really implement it makes your life much easier? And this is how the demo is going to look into. Now, if you can see on this slide, this slide you might have seen in previous keynotes, previous sessions, and this is a very important factor here. How a developer can start the journey from your trial and onboarding, getting your applications to be deployed across your IDs, your multiple extensions on an ID, multiple tools you use, such as Podman Desktop and other stuffs. Once everything is taken care of from your development workflow, now you want that code to be deployed on something which can be a container, which can be OpenShift running on GitOps, OpenShift running on AWS, and multiple scenarios. And everything taken care of, then your applications gets deployed and then you can measure their observability, monitoring, and other stuffs which runs on a production. So this is a scenario where a different workflow is taken care from starting to deploying a code and production. Let's get started with what we do with trial and onboarding. There are two scenarios right now which Red Hat supports for a developer and everything is open source currently, right? So we have Red Hat Developer Sandbox which allows you to provision a cluster of OpenShift running for 30 days. So you as a developer can go, sign up for a cluster and start using it and see how you can get your normal applications to be deployed on a Kubernetes cluster. Very simple, very easy to do that. The second important stuff is Red Hat Developer Hub. So you as a developer have to walk across multiple stuffs. You have to write your code on an ID, you have to see the CI pipelines, CD workflows using Argo CD, you have to also work with your QA engineers to see how those bug tracking are happening. You have to also work with your product managers or project managers to see how the workflow is defined. So multiple scenarios have been clubbed together as a single pane of glass which is known as Red Hat Developer Hub. I'll keep more deep dive into what is Red Hat Developer Hub, how things work, but this is a short summarization of what exactly it is. So the basic question a developer asks is, okay, guys, let's build an application. What we'll do, okay, let's me grab my favorite ID. It can be Visual Studio Code, it can be IntelliJ, it can be anything, let's say, clips for users. I wrote my code and done. But no, are you done that way? No, you're not done. You have to do multiple steps again, right? So the thing comes later is, this great stuff, okay, I need a container image, I need a container registry. So multiple challenges there. So the developer tools, what we are currently going to demo is, it allows you to simplify that entire experience where everything is present in one place and your knowledge curve is very much easier to understand, okay, this is how it is done, this is how it will impact my workflow and this speeds up your development scenarios. Once that is taken care of, you understand, oh, now I have to learn multiple YAML files, multiple CI CD workflows to deploy it, it gets very much confusing. And trust me, I was a developer and I know this sometimes becomes a very pain point to learn multiple steps because technology keeps on changing every six months and you have to learn something new. But let's see how this person says, okay, this is a simple thing, let's do it, can we do this? And we say, yes, we can do it. So the next step is, how can you do it? This is where the cloud native workflow started with. If people here are aware of how cloud native landscape is and how things work, this is how it started with and this is how it's going. Multiple projects, multiple scenarios and you as a developer have to learn and understand, okay, how that is going to improve your productivity, how everything is taken care of. Now, with developer hub, everything comes as a plugin and can be integrated as a single pane of glass, so you don't have to look around multiple scenarios. This is a code which resonates a lot with multiple developers and multiple people who work around these solutions are inconsistent onboarding experience. Let's say you have a team of five developers who are already working on a project which has a deadline of two months and you've got a new engineer hired in your team. Now, the challenge for the team is to get that new engineer onboarded quickly with the workflow which already is there, right? And it becomes very trickier because it becomes for the new developer to understand the nomenclature, the challenges, and also it becomes sometimes a bit costly for the entire company, right? Now, this can be solved into multiple scenarios. For example, let's say this is a scenario where you have to have a web application, you have to have a database connected to it, you have to have multiple SaaS APIs and as I said, the new buzzword in the industry, AI to be integrated into it. Once you get everything sorted out, then your workflow starts which becomes trickier for a new onboarding experience. So to solve that challenge, Red Hat has come with a scenario which is internal developer platform. This is an open source cloud native project which is known as Backstage and Red Hat is building on top of it. To give you more context, what exactly is an IDP? An internal developer platform. This is built by platform engineers, platform team to enable developer self-service so that once you start your onboarding process, you don't have to learn multiple scenarios. It's a self-serviced stuff. Developers are guided with multiple golden part templates, multiple scenarios, how you can start your project from a cluster, directly deploy to a production. Everything is predefined and you just have to proceed with the self-service mechanism and it involves multiple technologies and tools. Let's say I am working with GitHub Actions to deploy my code. So I will have a plugin on IDP which is having GitHub Actions and I get it done. Okay, and now I want to see how ArgoCD works with it. So I will again integrate that ArgoCD stuff into it and that also works out of the box. So for multiple technologies and scenarios, there are multiple plugins supported by a cross community. It's just not that, okay, Red Hat is working on it or just Spotify is working on it. It's supported by a cross community. So let's say you want to have a service now integration into your project. So service now has a plugin which you can directly integrate into your IDP and boom, you can get started with service now. You want to integrate with JIRA. Okay, Atlassian has a plugin, integrate with IDP, great. Now you integrate with JIRA. So this is how it improves your developer productivity because now you don't have to switch between multiple workflows. You have everything at one point. IDP platform is going to empower everyone in your team starting from your operations, how automation deployment and other stuff take care of including your security team which manages, okay, is there any vulnerability in your project? How challenging it is to remove that with new deployments, new GitHub workflows, how easy it is to make sure, okay, the code is safe and secure. And even for project managers, they can multiply and see that, okay, with multiple projects which are interlinked together, how that is there into a single dashboard. So same dashboard can be used across by the operations team, by your security team, by your PM team, and even for your QA team to quickly raise a bug and say, hey, guys, this bug is not working on the production. Let's roll back to a stage instance. So as I mentioned, Backstage is an open source project which is used to build these developer platforms, right? It's a cloud native computing foundation supported and Red Hat is an important partner for it. If people are not aware of it, it has scaled a lot of customers in the last one year. We had a very interesting session at BackstageCon which happens for KubeCon. And luckily we are having KubeCon in India in 2024. So folks who are aware of cloud native stores, it would be a really interesting thing to have that in Bangalore. So this is something which allows the developers to focus on the specific thing which they really like, is to write code. Now, when you write code and your job is done to navigate multiple tools related to your code, you have to just go to the IDP platform and done. Everything will be there. So you don't have to learn a specific thing or something new to just get your stuff done which basically improves what? Your developer productivity. If I need to deliver our Java project integrated with a goal and service, I can just focus on that and let my CICD, monitoring and other stuffs be taken care by the platform dashboard itself. As I said, let's say I'm a developer and I have to work with multiple stuffs. I need to know what Git issues are there, how I need to deploy my code using Quay. Oh, I need to have a Tecton build running. Oh, I need to have an OpenShift view to see how my applications are deployed and other stuffs, right? So this is a challenge a normal developer will face with working with multiple systems. Now, what Backstage provides you and eventually Red Hat Developer Hub will provide you is, guys, you just focus on coding and we are going to support you with multiple plugins within your Backstage applications. As I said, whichever technology you look interested into, it will have a plugin and that gets integrated very easily. And this is an ongoing effort, which means that communities are quickly building on top of it. Let's say you don't have a plugin for a specific tool right now, but down the line community works on it and the tool gets integrated into Backstage, eventually gets integrated into Developer Hub. So that's an ongoing process that keeps on increasing. How do you see these plugins? You might say, oh, there are a thousand of plugins. How will me as a normal developer have an access to those type of plugins? So then comes the concept of software catalog. So now that catalog have a set of plugins integrated, already installed, and that way your company can define, okay, my company needs these type of plugins because I work on, let's say ServiceNow, I work on Jira, I work on GitHub Actions. I have these type of plugins already integrated into my software catalog. You as a developer then don't have to worry, okay, from where to search, from where to get it installed, everything is there, you're on your cluster. Now, let's say you have everything taken care of, you have the plugins, you have everything, but you don't know, let's say you're a new developer, you don't know, okay, I want to deploy my Node.js with a MongoDB database on top of a running Kubernetes cluster. I'm really new to that technology, I am not aware of it. So what a Backstage and Red Hat Developer Hub will eventually provide you is something known as golden part templates, which basically will be a set of guided steps where you have to provide, let's say your application is deployed on GitHub, which is a Node.js application, you provide the URL, your application gets there, based on multiple workflows defined, you can say that, okay, this application has to connect to a Mongo database with connected URL written with environment variable defined, do multiple clicks then and done. So that's a golden part template which allows you to start your onboarding process. Let's say you want to make multiple changes, so your code is already there, make changes and boom, you're already up and running. So golden part templates are a very critical part of this entire developer experience. Let's come to something what we really do right now. So as I mentioned, Red Hat Developer Hub is based on top of Backstage, it's an enterprise supported product which is going to be generally available on December 12th, 2023. So it's next week and we are really excited, we have a very great list of customers who are already onboarded top of it, we have people already using it with early access program and we hope that community and the enterprise customers will get onboarded with this product. Now as I mentioned, Red Hat Developer Hub, let's focus on specific to what Red Hat Developer Hub provides you, right? So with Red Hat technology integrated across, like you have OpenShift pipelines, you have multi cluster views, you have container image registry, so everything together is integrated into this dashboard which is known as Developer Hub and all these plugins will be provided to you in that. So what advantages provide? As I said, it's a single pane of glass for everything there. It's a self-service stuff, you know how your CSED looks, how your GitHub actions look, how a Jira look, everything there and it also supports the best practices. It's, as it's supported by Red Hat, it is recommended that, okay, this is the best practice to deploy your code on GitHub, GitOps, this is how your application currently looks, this is how your infrastructure currently looks. So you know that this is the right way to get my application deployed on any running on hybrid cloud, be it OpenShift on AWS, OpenShift on Azure or any normal Kubernetes cluster. So this is a stack which currently Developer Hub uses. As I said, these are the set of plugins which we already integrated. These set of plugins will keep on increasing down the line. Currently, we have multiple support on Argo CD, Tecton, Key Cloak and Topology's views, et cetera. And some of the plugins which are already supported by the community, right? You want to integrate with GitLab, you want to integrate with Jenkins, Argo CD, any specific community plugin is already integrated. It's built on top of Backstage which is an open source CNCF supported projects which has a lot of support from Red Hat, Spotify and multiple other companies. And the supported deployment, as I mentioned, you can deploy your code on anything running on hybrid cloud, OpenShift on AWS, OpenShift on IBM running or let's say any managed Kubernetes services. So anything, your application is going to be deployed. So you don't have to worry about, okay, what's my infrastructure going to be? Is my application going to run on OpenShift? It is not going to run on OpenShift. How different it is? So everything gets integrated there. So enough of the talking, enough of the heads up and how things are. And I would be really happy if you will see in the demo because live experience makes a lot of feel. A fair warning, this is a live code, live OpenShift cluster running. So things might work, pipelines might drop. But this is how a challenging life of a developer would be, right? So let's get started to see how our developer would be with Red Hat Developer Hub. So this is a developer hub instance already deployed, just for the sake of the demo because we always have time crunch with these sessions. So my application is already deployed on developer hub. Now when I say developer hub, how does it look, right? So if let's say go to home and it says, okay, welcome to Red Hat Developer Hub. So on the landing page itself, you will see, okay, what type of developer tools are supported? What type of CI CD tools are integrated? Which cluster of Kubernetes is already running? So we already have OpenShift running there. We already have integrated with Argo CD, Quay, and Sonar Cube, and set of developer tools which are already integrated. For now, we have integrated Portman Desktop. Down the line, we are also going to add multiple scenarios around multiple VS Code extensions, IntelliJ plugins. So if you are a developer who works on Visual Studio Code and you want your extension to be integrated with this, developer hub, that will also be integrated down the line. If you're working on an IntelliJ user base and you want to work, let's say, dotnet application running on, working with IntelliJ and getting it on the developer tool scenario, so those type of stuffs will be integrated down the line. Okay, so let's go and do something creative here. So I'll go create. So as I mentioned, we have set of golden part templates. As you can see in my scenario, we have an Ansible job template. We have a backend with CI integrated. We have a Node.js application. So any scenario, let's say I want to work with AI. Hey, guys, that's a buzzword. I want to create an application. Or does the POC of my Python app is running on AI? But I don't know how to start with, right? You go to developer hub. That's what is there with the pipeline. And we say, okay, deploy a Python app showing generative AI using OpenShift AI. So in the last session, you might have learned about that Red Hat is also coming with a product which is known as OpenShift AI. Red Hat Data Science, it was known as previously, but now we have the brand new name which is known as OpenShift AI. And they are doing a great work on making sure AI workloads and everything getting deployed on your OpenShift cluster. So these type of golden part templates allows you to get started with applications quickly and understand how things are. Now for this demo, what I'm going to do is I'm going to deploy an game which is running on OpenShift. And it is built using Quarkus. So I'm hoping people are aware of Quarkus, but Quarkus is a way to deploy a Java application using cloud native principles, right? And it has been a very successful effort from the Red Hat community and other communities to make sure Quarkus is one of the leading factors in application development if you're a Java developer. So let's get started with this. So I say, okay, I want to start with my Java application with a game running. So I say, okay, let's go and start it. As I mentioned, we just need few details and the application will itself determine what's the next step. Okay, my organization name is WinTurbine Inc. So WinTurbine Inc. is a company which allows you to run a game using multiple scenarios like, okay, I have a game running, I tap on the phone and let's say energy is generated and based on generated energy, my car moves running. We'll be showing that in the demo. That should be a very cool demo. I provided a Git organization. Let's say your company already has a different organization on GitHub, you can provide that. I'll provide a description and let's say next step. This is where the namespace comes. This is where the... I've already deployed this game so I'm just going to showcase you how things can be done so that we can directly jump onto the game itself and see. I provide the namespace and I provide, okay, which is the user which needs to own this? So in a company, you can have multiple GitHub organizations, GitHub repositories, and users will have different permissions, right? Let's say a platform team has an admin access, but a normal developer doesn't have access to... access that stuff. So in this way, you can define that which user has what type of permissions and you can define, okay, which owner owns this. Once you're taken care of it, let's say I provide demo definition, I say user is Mohit and I say next. This is the image registry which I want it to be deployed. Your company might have their own private registries or their own registries. You can provide that. You can provide which tag it needs to look into. Let's say you are already working on something which is cutting edge and that's not on the latest, but that's on a different branch. So instead of providing latest, you can provide, okay, I'll provide a different tag name and I can just try to do it. I said do next. And this will give you a summarization that, okay, this is how it would be and as soon as I say the create, it will start creating an application on my OpenShift cluster. So let's go and see how that looks. So this is my OpenShift cluster which is already deployed and this is OpenShift running on AWS. Similarly, you can work with OpenShift on Azure, OpenShift on Google Cloud, IBM Cloud, any type of hybrid cloud cluster should work out of the box. And this is a topology view where we can see, okay, what type of applications are already deployed on my cluster? What's the view of it? You can see multiple workflows around what's the build config, what's the deployment config, what's the route of the application and other stuffs. So as you can see here, this is what my application is currently there. So let me click on it. As I said, you can see, okay, with pods are running, what services are currently running, how the port forwarding works, and other details, right? So my app is already running, so let's get started with that. So what I'll do is I'll just go here. So once that thing is taken care of, so what I'll do is I want to see, okay, is my application really deployed or not? So I go back to my developer hub and I say, okay, let me go to catalog. So in the catalog, you can see, okay, I have these many applications already deployed. Now I have to see which application I did currently. So the name was Summit, so I do search, and this is the application which is running, and this is how the application currently looks. Now you can see, okay, this is my pipeline, this is how my deployment config is. If I want to make a quick edit on the repository which is there, I can open in Dev Spaces. So OpenShift Dev Spaces is a cloud ID which allows you to write and edit and deploy your codes using Kubernetes and OpenShift. Now, okay, I want to see what my GitHub repository, so I'll do open in this way. So from the single dashboard, I say, okay, this application was deployed. Now, okay, I want to see, okay, let me see what's the current pipeline of it. Is it running, is it not running, is it deployed, not deployed? So I go to the CI tab of it. You can see this is a single dashboard where you can see from a topology view from a Git tracking to a PR request, from a Tecton pipelines, everything together. Okay, great. So I can see my Git was cloned, packaged, and it's already deployed. So my pipeline is taken care of. Now I need to see how my ROCD history looks like. Okay, so application is already deployed and other stuff, so this way it works. Now, let's say I want to integrate with Tecton, right? So if my Tecton instance is already running, I can see, okay, what pipelines runs are running, and which one failed, which one did not fail, everything one single dashboard. So you don't have to go to a new dashboard to see your pipeline runs. You don't have to go to a single view where you have to see Argos it instance running. You don't have to go to a single, different view to say, okay, how to raise a PR request, how to do a GitHub actions, everything at one point. And the other interesting stuff is, if you want to have a dedicated documentation, you can have a docs tab here, you can provide multiple documentations around your workflow, so the new developer gets easily understanding that, okay, this is how the thing works, this is how I need to understand. So the next stuff is, let's see how the deployed application looks. So as you can see here, my application is already deployed, I can see my route is already there, which means that my application is running. So before doing that, I would like you guys to, and we'll play a live game together. So this would open up a tab in your browser which should reflect the similar scenario that waiting for game. And once that is done, I'll start the game and then we'll see how that deployment actually works. So the basic understanding here is, I had a Git repository, which had a Quarkus code which used to deploy this application. So using Red Hat Developer Hub, I deployed that Quarkus code to my OpenShift running, and this is how the game looks like. And once we make certain changes, we will see how that pipeline affects and everything will be done through the developer hub. So this is my admin dashboard. Let me refresh it to see how many people are already in it. So let's play a car racing game between Chennai Super Kings and Royal Challenges Bangalore. I thought of a different name, but I thought, okay, why not to play with RCB more? Hopefully they'll win this time here. So let's start with this. So you can see multiple players are already signed up, right? And you can see on your phone, you might be seeing a loading car, right? The game has not started yet. So as soon as I start this way, the start, you have to tap on your screen. There will be a windmill, you have to tap on your screen and whichever person wins. Yeah, so if you want your team to win, please tap more so that because it takes the count that okay, it's divided equally between number of players playing. So try to make your team win. Try to make RCB win this time, please. So one, two, three. Come on, you can see the car moving, right? Come on, come on. Yellow, yellow, yellow. No, no, no, again. So this time also we are making the team lose. Come on, guys. So I think Dhoni effect is still prevalent here. So, good job. Esal Kapnamdhamma, good job. So, as you can see, the best part here is you can see the dashboard URL. Okay, let's see the leaderboard. So you can see that energy generated with based on your tap. That okay, the tap you made, the more tap you made, the more energy generated. This application is running on Quarkus, which is Java on Kubernetes. And based on that, you can see the leaderboard between CSK and RCB. Now the interesting part here is, okay, now we did with the tap system. Can we do something else? So let's say a company decides, hey guys, we need to make something innovative because the competitor company has come up with the same game and we need to be unique. And it's Friday, 6 p.m. We have to go to Bangalore to have good drinks, right? What to do? My team has said, okay, I need this by Monday, Saturday Sunday I don't work. So let's quickly deploy something. So this is where Developer Hub will quickly get you started. So what we do is, what next step is, you see you saw the inner loop scenario, where you did this, all this code on your Quarkus application, you get it deployed. Once deployed, it will be having a pipeline's running, everything is taken care of. All the scenarios are there in Developer Hub. So now what we have to make changes to, instead of tapping, we have to shake our phones. Hopefully don't make it fall, but that is how it should work. So what we do is, as you can see, this pipeline is already running, right? And if I go to the overview, my gate repository is here, so I do go. My gate repository is open. This is what my wind turbine app looks like. And let me do this. And this is the configuration file. Just quickly, this is the repository. If you go to the repository, you can see how things are. So if you see here, I need it by Monday, it's Friday, 6 p.m. I need to go quickly from Kormangala to Whitefield and it's traffic. So what I'll do is I'll quickly make change. Right now, the shaking part was false, right? So I need to make, now shaking should work. So what I'll do is I'll quickly edit it. The best part here is, instead of editing directly from your GitHub or whatever it is, you can edit these repositories directly opening in Dev spaces, right? What, when I say Dev spaces, what we do is you go here, this application, and open this in OpenShift Dev spaces and make certain changes there. So the other scenario is, let's say you already have your applications running on your ID, right? You're using Visual Studio Code and you want to deploy that application using VS Code. So what we do is we go to VS Code, right? And you open that workspace, that Git repository here, and there's an OpenShift extension already enabled in Visual Studio Code. This extension is already also in IntelliJ. So what we do is we get that application there, we make certain changes, and we say deploy to OpenShift. So that application gets deployed. I won't go a lot of details there because of time constraint, but let's for the demo, okay, I need to sign it to GitHub. For the demo, I need to just make some changes here. So what I'll do is I'll enable this, correct? And I say commit. The similar thing you can do from your ID and make quick changes. As soon as you make these changes, the commit is done, right? So what I do is I go to pipelines from the developer hub instance because I made that change, I go to the pipelines. You can see a new commit already started, 1147, right? It's now 1148. And you can see the status is running, which means whatever changes I made on my Git repository currently with one quick fix, the pipelines automatically recognizes it. You can open the same pipelines from a dashboard of developer hub. You don't have to switch between multiple tools, single pane of glass, everything is there. Once that is taken care of, we'll have a new way of the same game deployed. So instead of tapping, we'll be playing as shaking. As I said previously with a pinch of warning that, okay, the pipeline might take some time. So meanwhile, we'll go through our sessions and see what exactly we want to do there. So if you see the developer experience overall scenarios, the best part of the Red Hat developer tools that we talk about was, you can get multiple tools and technologies. Let's say we have set of VS Code extensions. Right now we have a Java extension on Visual Studio Code, which has more than 30 million installs and is the number one extension for anything related to Java experience. We have a joint announcement today with Red Hat and Microsoft together for the future of Java ID extension for the next six months. Right now it has three million active users. Similarly, on IntelliJ, we have set of plugins for Quarkus, OpenShift, Techton, other stuff. We have Portman Desktop. We have multiple tools which allows you to work with such as Developer Hub, Red Hat Developer Sandbox. So that comes around tooling. Now how to work with those toolings, right? So you have documentation around it, tools around it, and multiple programs. Dev Nation Day is one of them where we empower developers to understand what features Red Hat developer tools provide you and the content. Everything is available on YouTube. Blogs are there on developer.redhat.com. You have hands-on tutorials where you can get started with. And the best part, everything is free and it's all open source. So it allows you to quickly get onboarded without having multiple pain to, is it free, not free, how easy it is to understand, and other stuff. So let's go to see what, how my pipeline looks like currently. It's still running. It's in the second stage. So it should be quickly there. And once it is taken care of, we would be seeing how the new applications get deployed. So let me tell you one more stuff quickly. I think I have time. Great, I'm on time. So one more thing which we can do quickly is, as I said, we have this Argo CD history here where we can see what applications are there, how things work, and multiple stuff. The other stuff is, let's say I already have an application which says, okay, this is my wind turbine application and it was created by one of my team members. And I had to review the PR. So instead of verifying that where the PR was raised, was I added as a reviewer or what's the comment from other team members, you can see everything from the same dashboard. From the documentation point of view also, we have multiple documentation to understand how a specific application is deployed, how an specific application works. And this is a cluster view which, okay, so I think there's another, okay. So let me quickly do this. I think our pipeline is running. My pipeline is taken care of. So let's go and, let me do this. You see, now, instead of doing a tap, we have enabled shaking into our application. So what you guys have to do is, you have to do one more scan of a QR code and we should be good. So can you please scan this QR code? Look, okay, and let's make our favorite team win. So once you have scanned, right, you can see on your application instead of that rotating car, you can now see enable shaking, correct? If someone is not seeing, let me know please, that might be a very unique experience, but. So let's go and see, okay, I will refresh this. So I'm still waiting for the players to log in, right? So now, if you can see, instead of tapping, you have to shake your phone. Faster you shake, it takes on the average gravitational there and based on that, it detects which car will win the race. One more chance to RCB in all these 12 years or 15 years, whatever it is. Let's make it win. One, two, three, go. Come on, come on, come on, yes, you lost it again. You can still do it. We should take a photo of this. I should. Good job guys, very good job. So you can see the best part here was, with few changes in your gate repository, with few multiple workflows defined in your developer hub, you can get an application which was using a different scenario of tapping and now you can do a shaking and your game is already deployed, right? So now you can go on a Monday morning, Monday blues are taken care of and you can tell guys, our code is deployed and we are leading with the great game developed, right? So this is how the entire workflow of developer hub basically works, right? Quick deployment, quick scenario changes, make sure that changes are already taken care of and you have your plugins already integrated, you have golden part templates already integrated. Let's say down the line, we want to integrate the same application using generative AI, running on OpenShift AI, right? So after this, we have a session with Ramqi and other folks which we'll talking about how OpenShift AI is going to empower developers, allow customers to deploy their AI workloads and this is easier will be integrated into developer hub also down the line, right? So this is a quick scenario how developer hub exactly works and I hope folks will try it out. It's based on top of backstage, as I said, so it's an open source project and if you have any specific plugin which you need for a developer experience, you can raise up GitHub issue for that, that okay, this is a plugin which I need, which is currently not there in backstage ecosystem and we can integrate that on Red Hat Developer Hub. So from where to get that, so you just have to go backstage.io slash plugins and this will have set of plugins which are already there. So all the plugins which are work with backstage will work out of the box in Red Hat Developer Hub and it's very easier to request a plugin that okay, this is how this plugin I want and Red Hat will work with that company, with that ecosystem to make sure that plugin is already integrated. We have seen multiple requests coming from developers that okay, I need an integration with service now, I need integration with JIRA, I need integration to see as your pipelines is working, right? So you as a developer might have a specific technology stack which you're working on and you want that to be there in backstage.io if it's not there and Red Hat will take care of making sure that experience is taken care of. So that's it from me. I hope you like the demo, I hope you like the session. Feel free to reach out to me. I'm available after the session too and I said I am very active on Twitter and LinkedIn. So feel free to reach out to me if you have any specific questions, you can drop a mail on devtools-pm at redhat.com. So that's the team which we manage and we will be very happy to answer some of the questions. These are some of the reading materials what we have if you want to get started with Developer Hub, Red Hat ID extensions and Podman desktop and hopefully this session has given you a great idea that what exactly Developer Hub is, how it empowers developers and what are the multiple tools and technologies Red Hat Developer Tools is bringing to the community. So you can join Red Hat Developer Hub, it's free completely for everyone and thank you for your time and it was really great to interact with you. Next year, see you in Bangalore again. Thank you. Yeah, so let's say I'll repeat the question for everyone. So the question is, if a developer needs to define their environment variables or such scenarios, how we can do on Developer Hub? So the best part, let's say you have an OpenShift cluster or let's say you have any hybrid cloud cluster running and you have to define your secrets or environment variables. So those can be already integrated even when we say OpenShift topology view. Once you open that, that gives you a perspective of Red Hat Developer Console which has multiple scenarios to define your secrets, see your workloads, specify your environment variables. Even in the golden part template which we defined, in those also we have certain scenarios where let's say you're connected to a MongoDB, right? And you want to specify the environment variable how the database will eventually connect, right? So there the environment variables will be there in that golden part template itself which you can define and just say create and that will be taken care out of the box. Even this application, the Quarkus app which is running, it has multiple environment variables and those environment variables are either defined in the Git repository with multiple secrets or it was defined in the Developer Console workflow. So that way you can define those scenarios whichever is preference from a developer. Placeholders need to define in code itself. Yeah, so the best part here is you as a developer have not to change your workflow. As normally you were walking previously, you're still writing the code the same way, you're doing everything the same way. The only benefit right now here is you're getting everything under one dashboard. So you can see, okay, how my pipelines are running, how my Argo CD is running. If I'm integrated with GitHub Azure, whatever it is, how those behave, okay, I need to see what my PR requests are, okay, I need to see how my service now ticket has done. Everything under one dashboard, that's it. But you as a developer still have to do the same job of coding. It relieves you with multiple infrastructure workflow and just focus on writing better code and good code. So definitely this will be a huge success. Just wanted to know like when people will start using there will be a requirement for plugin. So how soon, what is your like scalability approach or future anything in your mind so that like we cannot wait for one month or two months for getting that plugin and then start working on that. So right now the plugin ecosystem is very much integrated with the entire community. Even as we speak, we have multiple plugins which come from multiple vendors. So we have a discover, as I mentioned, right? We have a discussion with Atlassian going on. That hey guys, we have a very great interest coming from customers, partners and developer that they need to get their Jira integrated quickly. So that we will discuss with the company to make sure they get their plugin quickly because there are two scenarios here. Let's say you have a Jira plugin, right? You're already in backstreet.io and you want to use that plugin. But what if that plugin is coming from a developer who is not Atlassian, right? They have masqueraded that plugin. They have a malware into that plugin and you install that plugin, okay, great. Now your company is fully infected. So what Red Hat Developer Hub is trying to do is they want to implement a scenario where whatever plugin which gets into Red Hat Developer Hub is coming from a certified publisher. When I say certified publisher, it means, okay, it's coming from Atlassian. Red Hat says we trust Atlassian and that is why it is safe. And Red Hat Developer Hub will provide a mechanism to scan the plugin, to provide the vulnerability scanning and everything to make sure that when the end user uses it, they understand that it's coming from a trusted source. Now with respect to the stability that how quickly it can be integrated, it would depend upon type of plugins, right? There might be some plugins which are very quick to integrate and make sure, okay, now your experience is simple. It will be very quick. But let's say there are some plugins which require multiple integrations with all the tools also, some dependencies with other tools. So that might take some time. But the best part here is we have a dedicated team, a partner ecosystem team at Red Hat, which works very closely with the Red Hat Developer Team to make sure the entire plugin ecosystem which is there on backstage at iOS at last plugin gets integrated into Red Hat Developer Hub. And we're actively building on top of it so that more plugins get integrated into it. If you have seen Visual Studio Code, right, there are gazillions of extensions out there, right? But you would only verify certain extensions which are coming from verified publisher. So same concept we have tried to integrate into Red Hat Developer Hub. So whatever plugin which is coming from a verified publisher, that will have a verified tab or what badge it on the dashboard so that you can quickly scan, okay, this is the right thing to install. Because one, let's say I'm working on GitHub Actions. Any developer can go and create a plugin backstage at iOS using GitHub Actions, right? But if that plugin is coming from GitHub, it makes more sense for the developer to use. And this is where Red Hat Developer Hub is trying to empower the community to get a certified plugin ecosystem down the line. So as I said, the GA of Red Hat Developer Hub is December 12th. After the GA, we are trying to integrate more plugin ecosystem and down the line, you will see more announcements around it. Yeah, so we already have set of multiple plugins integrated into Red Hat Developer Hub, catering to multiple workflows for developer. As I said, okay, right? We already have CI, CD integrated. We already have GitHub integrated for PR merge request. We already have Argo, CD, GitLab. So what are the top vendors and what are the different tools a developer would need in a daily workflow? Those plugins are already integrated. But if there are something specific which they need, let's say down the line some crazy technology came into the market, right? And every developer on booted onto it. This is what happens with developer ecosystem, right? So that type of plugins will also get integrated down the line. One of the very interesting road map like the other guys would be doing is with respect to OpenShift AI. We want to integrate that workflow on the Red Hat Developer Hub. We want to make sure the other Red Hat tools and technologies which are still not integrated into developer hub will also get embedded into it. That's a short term road map, what we have for that. And the long term road map is to empower the entire backstage community, right? Right now, Red Hat is one of the leaders in the backstage community, but we also want to empower a lot of backstage community because if the backstage community grows, it eventually will empower the Red Hat Developer ecosystem overall. So OpenShift AI is one of the important aspects what we are looking for for Red Hat Developer Hub. Demo was really good, I liked it. Okay, one question I had is like in the demo, we have seen that we were able to build and deploy a single project, right? Let's say I have a scenario like I have multiple projects and I want to build in a specific sequence. How do we specify that? Yeah, so you can define those deployment parameters given configuration in YAML, right? So let's say, as you said, you have multiple sequence that says, first, this application needs to get deployed. Once this successfully is done, then we move to the second one, right? That's how the sequence, that sequence can be defined in a given YAML and the Argo CD instance will take care of it. Okay, thanks. To answer your question, you need to define something called the software templates. So these software templates can be with multiple projects. So this is something with the software architect or the DevOps person or the platform engineer within your organization needs to do. You need to define the software template like I showed in the first demo and what Mohit showed. So you need to create different scaffolder templates for various projects within your organization. And then once you have these projects in place, then you can... So these are again, simple YAML templates which you need to write. You can mention the sequence. Like certain common sequences if you're trying to do a complicated setup. Like complicated setup when I mean you have certain applications running on OpenShift as a Kubernetes deployment. And then you want to work with like, say, SAP Oracle kind of workloads where those database systems need to come up by itself on a separate cluster. And then you want your applications teams to start working with that. You can define those things also if you want to define a time out. So what happens is all of the things what you're defining here will translate back as YAML manifests for Kubernetes when you're setting up the environment in the backend. So that way, how much ever... So this is like for the platform engineers, if you know the patterns, what the developers are asking you within your organization, because right now by now you would know what and all are the requests coming up from the developer teams. Some teams move very fast. Some teams like to be on the bleeding edge with OpenShift. Some teams want to work with enterprise supported tools. So you'll have a pattern. So based on that, you can automate your tasks with this. And any time a group asks for, okay, we need such and such setup, you can also automate it for it to be like self-service. You can integrate it with service now and then that went triggering a template over here and it also generating it. Or if you want to go further, you can create a language model using generative of your own company's request, like how they're coming and it can also generate out a template saying that give access to X number of groups with Y number of people and generate out only these versions of templates out. So you can do all of those things. But the thing is, this is like a one-time effort. So you need to sit with the software architects, delivery leads and write out this template. So let's say your code is getting deployed via Jenkins, right? So then you have to go to a new tab, open a Jenkins dashboard and you do everything. Then again, come back to a different tool and do everything, again, go back. In developer hub, you have your code deployed. You can open the Git repository, make changes. In developer hub itself, you can have a Jenkins plugin integrated and there you can see, okay, what builds are running, which builds fails and everything. So that way it allows you to integrate your Jenkins pipeline directly into developer hub. It enables you to quickly deploy or write your code rather than switching multiple workflows, right? And you can define permissions also. Let's say you are an admin and you want certain specific roles only to be defined to certain users. So you can define those in Red Hat developer hub so that not everyone will have access to that Jenkins build, right? Only certain group of users will have. So everything can be defined using the same workflow in developer hub. Thank you so much. So one last thing is like, for example, just Jenkins, right? When you are used to Jenkins, you need to spend some time thinking about the capacity, how much this Jenkins server requires, and all of that. Here we take a different approach. We use Tekton for our continuous delivery. What we do is we look at the resources which are available within your own cluster, then trigger the build pipeline like any other Kubernetes project. So you can finish your project, your build and integration project with Tekton. Once that is free, again, you can reuse that service. So that way you don't have to have dedicated systems and all to run Jenkins in a separate way. You can use the existing cluster, build it, and then deploy it from there itself, and then reuse the cluster. And basically it's a different tool, right? So let's say she's using Jenkins, they're using Azure DevOps, and any other company have their own set of deployment mechanism, right? So it's your preference, but the entire advantage of that is in developer hub, you can still integrate that. And as Ramqi mentioned, Red Hat also recommends certain workflows. Let's say recommend use OpenSheet pipelines to properly manage your resources, properly do a quick deployment. So those type of things are there. The differences can be like, how Azure DevOps is different to GitHub Actions, that's like completely different with different products, right? But... Feel that it is based on similar kind of that ADO with this developer hub. That's why I just want to compare with this tool. But with developer hub, you can do multiple stuff, right? It's just not deployment, right? You can, as I said, right? You can do like GitHub code management, CI, CD, AQA analysis of G and other stuff. So one part is how deployment works and you're using a tool which is known as Azure DevOps. In similar case for ADO also, just you need to edit the code so that it will start your pipeline and it is getting deployed all the way. So one thing, I mean, see, there are many developers, this space has a lot of tools and a lot of opinionated way of how developer experience needs to be. And there are more than, you know, I can think about 30 to 35 tools in the same space by various companies, open source projects and also large... But the thing with, like, say, using developer hub, integrating it with Argos series, say, for example, you want to deploy your applications to AWS in one region, Azure and your private cloud in the second region, and in the third region with their own private data center with Google Cloud, okay? You can create templates over here once you have your build. Like, for example, he showed the game, right? The wind turbine game. So you want to launch it to a new market, right? So it is very easy with this. All you have to do is have credentials in that particular cloud and get the same kind of environment and you can trigger the builds over here and you can deploy to all the three clouds also, multiply. And also, not only multi-cloud, but also a private cloud, multi-cloud does it. Red Hat's unique strength is hybrid cloud. So if you have applications which are on private cloud, public cloud and you want to deploy applications, we can. It's great that there's a lot of interest for developer hub. So what we'll do is we'll talk about another interesting topic and then we can come back, so yeah. So I'll hand it over to Rahmaki and Ritesh. Thank you guys for your time and it was really nice talking to you. See you soon. Bye-bye.