 Good afternoon, everyone. So we have this session is mostly about the roadmap. With me, I have Kasturi and myself, Mohit. We work as product manager at Developer Tools. We look around all the toolings we support, and I will be going slowly one by one what we have and what we want to do. If someone has any specific query, please raise your hand. I want to keep it much, much interactive. And this is something which we would like to do even after the session ends. Ask the expert section will be there. I would be there. We have this red batches and t-shirts. Feel free to ask any questions. So let's move ahead. So if you see, this is the end-to-end developer flow, right? From the morning, you have been listening about what we want to do from the developer perspective, what is the scenario Red Hat is providing. So once we start directly from trial and onboarding, right? OK, I'll let the folks quickly in. So the first instance of providing a developer experience around Red Hat support is that you want people to have their Red Hat OpenShift clusters provided, right? So that comes under trial and onboarding, right? So that can be done either through Visual Studio Code, IntelliJ, or you have running on Docker, Podman, other stuff. We are also coming up with support for backstage down the line next year. The next step comes from a developer is how to develop their code from the, what should I say, the workspace. And that should be your editor. That can be any editor. You prefer it can be an IntelliJ. It can be VS code. And that is known as inner loop. What I mean by inner loop is that you write your code, you build, then you want to debug that. And once that is done, you push that code. So now as soon as you push that code, either you doing a merge request or something, it moves to an outer loop. Now in the outer loop, the scenario is that you do a code review. You do some compliances, security, and other stuff. And every scenario is inbuilt. Once those cycle is completed, you deploy directly on production. When I say production, that can be any open shift instance running on bare metal, open shift running on AWS, GCP Azure. So we provide multiple deployment targets. And that provides an easy interface for any developer. It should that let's say you want deploy your Node.js application running on OpenShift on AWS. So that provision starts from trial and it directly moves to onboarding. And then it moves to inner loop, outer loop, and your code is deployed on production. So that's the end to end flow. Now when I say end to end flow, these are some of the toolings what we support. So let's say you want to onboard an OpenShift cluster. So that can be done using developer Sandbox, which is hosted, or that can also be our OpenShift running locally on a laptop, which is known as OpenShift Local. The code is readily available on the developers.redhat.com. And it's completely free to use. Once you are done with that, and then you move to inner loop scenario, right? So you can deploy applications directly either using a Portman desktop. So we recently created a tooling on the same lines to allow developers to run Portman. The second can be if you are a Docker user, right? And you want to deploy your application using Docker on OpenShift. So there's also an extension level on Docker where you can provide your images, and that can be directly deployed on OpenShift. Third one would be, OK, I have a code, but I want to run that code on a cloud browser, right? This is something which has been tried by multiple companies. You have heard of code spaces. Redhat also has a similar offering, which is known as OpenShift Dev Spaces. So try it out. That's something which you can deploy your code on browsers. We have a specific session on Dev Spaces coming soon after my talk. Kasturi will be doing more in-depth detail, all right? The next one is ID extensions. When I say ID extensions, the developer mostly resides on their ID, right? Your code resides on your VS Code instance or IntelliJ instance. Now, to deploy those code either on OpenShift instance or you want to deploy a serverless, or let's say you want to create a pipeline using your code without leaving your editor, right? As a developer, you should have the choice that, OK, my code is in VS Code. I need to do everything from VS Code. So Redhat provides that tool. Do everything in one place. Don't switch between editor, terminal, browser, everything at one place. So that's where the ID extensions come into place. We also have a specific session detailing into this later in the evening at 4.30. I will be speaking more on that. The last one would be around CLI tools. Before this session, you might have heard we have people speaking about Odo. So that's a CLI tool which we have that works on the same lines deploying your code locally using CLI. Once you're done with this, and then you move to the outer loop scenario. Now, when you move to outer loop scenario, there are multiple scenarios like we saw with developer console. So you can create your applications, deploy your applications during the dev console way, or you can do it using Helm charts, or you can do multiple ways during pipelines, like Tecton, Hubbys, Supported, Pipelines, and Supported, and other stuffs. So let's go and see what trial and onboarding we have. As we mentioned, Developer Sandbox. So the main challenge what we wanted to fix was allowing developers to quickly provision an OpenShift cluster. So it should not be something that you have to pay for. You have to go and figure out where it is. It's readily available. It's available for free. Go and try it out. Any Kubernetes OpenShift cluster. And it should be preconfigured with development scenarios. Let's say you wanted to have certain templates or operators installed onto it. OpenShift Sandbox will provide you directly that. Now, the advantage of it is it requires zero installation. It's just one click deployment if you go to developers.redact.com. So if you see, there's a URL at the bottom. That's very simple. Just type Developer Sandbox, and you are good to go. Provision it. It will just ask you once the verification, and you're done. You wait on OpenShift instance for 30 days, and even you can extend that by a request. So that's as simple as it is. Now, once you're done with that, let's say you want to run your OpenShift local for multiple days, but still on your laptop, right? But the challenge there is for a developer to run an OpenShift instance, it will require certain configurations to be done. You need to know what Kubernetes does, and you have to understand multiple stuffs. But from Red Hat what we are providing, you don't need to worry about that. You just go ahead and install OpenShift local. It's available for multiple platforms like macOS, Linux, and Windows. And it works very easily that it provides your single node OpenShift cluster. You can just start on your laptop and get started with it. And it also supports multiple virtualizations like with different platforms, so that it becomes easier. It also has an installer for macOS, Windows, or you can want to run with a binary. You can still run that with a binary. So whatever a developer is comfortable with. Now, the next thing which we are embarking, and that will be coming something down the line in the next year, is providing a support for backstage. I'm assuming that many people might be aware what backstage is and what other companies or what open source community is doing around backstage. But this is something which Red Hat is heavily going to be invested into down the line. And if you see, once we move ahead, we'll see what Red Hat supports there for backstage. So I'm just going to give you an overview that what we are offering so that once you go to the Red Hat portal, you will understand that what are the supports, and it will be easier for you to understand. If you need more deep dive onto this, please feel free to ask the experts, and we'll be very happy to follow up on that. Now coming to the important section of it, what does inner loop support is, right? The first one is OpenShift DevSpaces. As I mentioned, you want to run your application or your code directly on a browser, right? So let's say you start with a pre-configured code OpenShift DevSpaces. So if you see on the slide, it's mentioned that, OK, it was known as CodeReady WorkSpaces, somewhere here, right? Because the previous name was CodeReady WorkSpaces. So we have rebranded it, and we have kept it as OpenShift DevSpaces. So let's see if you find some documentation on online and saying CodeReady WorkSpaces. It still means OpenShift DevSpaces so that you don't get confused. This is a simple URL we have, developers.data.com, OpenShift DevSpaces overview. This will give you a very easy guide at how to get started with it. The next one is an IDE extension where, let's say, me as a user, I have my Node.js application, or let's say a Java application, not .NET application. Any sort of application. I'm on my VS Code instance. My code is already there from GitHub or from GitHub wherever you want it. I quickly want to deploy that image on top of an OpenShift cluster. Usually what people have to do is they first have to provision an instance. Second, they have to go to CLI to install it. Third, they have to figure out, oh, whether my code is running on production or not? Should I go to the browser and check? Multiple different steps. What we are providing with OpenShift Toolkit is, forget about all these multiple steps. There is just one click deployment. Your code is there on various code. Just do one click, deploy an OpenShift, and it will basically figure out what should be the deployment method based on your Git repository. It will recommend you that this should be the deployment method. If you're fine with it, you proceed next. Once that is done, the code will automatically be there on your OpenShift instance. Now, the next part is, what if you make some changes on the code? So it always watches your changes on the code, and it continuously does a deployment on OpenShift. So let's say you as a developer want to test out some application. Is it working fine my OpenShift instance? You can quickly do that. Let's say you also want to test it on Kubernetes, like running Minikube or running Docker Kubernetes. That will also work out of the box. So basically the support is around provisioning any application on top of OpenShift or Kubernetes within one click. And it also allows you to directly provision any OpenShift instance from the VS Code instance itself. And this support is having the similar functionality if you are an IntelliJ user also. So we are targeting all the developers who are on VS Code, IntelliJ, and other stuff. Now, coming to serverless functions. Serverless is something which we want to also incorporate in our developer tools. And we want to provide the same workflow what we have for OpenShift. So now if you want to create a serverless functions, or you want to deploy an application directly using serverless way. So there's also a VS Code and IntelliJ extension, which is there available on the Marketplace. You can just download it. There's a link here. So if you go to VS Code Marketplace, you can download there. Or if you go to JetBrain's Marketplace, the link is available. So basically, the idea is to provide support around serverless also. Now, Red Hat is focusing a lot on Java development, Quarkus development. And this is something which we are targeting. If you go to VS Code Marketplace, the number one extension from Red Hat is the Java extension, which has approximately 19 millions, which is 19 millions downloads. And we work a lot with the communities. So when I say community, I mean Red Hat, Microsoft, Oracle, they work together to make a seamless developer experience around Java. And the same level of functionality is also incorporated when you want with Java and Kubernetes, which is Quarkus. The next one is, as I mentioned earlier, OK, I have my Docker image, but I want to deploy to an OpenShift. What should I do? Should I run a CLI? Should I provision something else? It's very simple. I think three months back, Docker announced that they are supporting extensions. So Red Hat has created an OpenShift extension, which runs on Docker desktop. You just have to go there. And you see, if you can provide your image there and just click on Deploy, it will basically start deploying your Docker image directly on OpenShift. It's as simple as that. And from here itself, if you don't have OpenShift cluster, you can provision an OpenShift cluster using developer sandbox, which is valid for free for 30 days. You can still extend it. So it's as simple. You should not worry that, oh, I don't have an OpenShift cluster. What to do next? You already have the workflow there, and you start doing it. Coming next, let's say you have your OpenShift cluster done, and you want to do everything from your CLI. You are much more comfortable on the CLI, not on the ID. Don't worry. We still have that workflow done. You can deploy your applications, test your applications on Kubernetes, on OpenShift, using this CLI tool, which is known as Odo. When I said OpenShift toolkit in the beginning, OpenShift toolkit basically uses OC and Odo together to provide you that experience. So whatever functionality you get on the CLI, the same level of functionality you will be getting on the ID also. So you, as a user, have multiple choices to deploy your application on OpenShift. And that's where we want to make sure your inner loop experience around this is much more improved. And this is the latest entry into that, which is known as Podman Desktop. There has been a lot of discussion in the community regarding Docker, Desktop, and what should be the alternatives and all. So Red Hat has come up with a new desktop tooling, which is known as Podman Desktop. It basically runs on Windows, Mac, and Linux, and it's currently released with the latest version. It also has multiple supports like image registry management, and you can configure your VPNs around it. And the best part is you have an application, the image, as you can do with Docker Desktop, deployment, and OpenShift, the same way it will work on the Podman Desktop also. So you, as a user, have a flexibility. You want to work with Podman. There's always an alternative, and you can start with it. Now, this whole scenario basically covers what we did for In-A-Loop. Now, coming to the outer loop section, the most important part is the developer console, right? So this also comes with pre-configured developer tools. When I say pre-configured developer tools, it allows you to run your operators. It allows you to configure topology view or observability. This was a session which we did before lunch, and this is what we are continuously improving upon. The best part is it allows you to have a very great graphical interface to do everything at one point, right? And you have two perspectives around it. One is the developer perspective, and one is the admin console perspective. And there is multiple getting started support on it. Let's say you don't know what you want to do with Node.js application or how the UI will behave. There are multiple getting started around it, so you, as a user, will be not in a state that you don't know and what to do next. So you just follow the guided workflow, and everything works out of the box. The next one is OpenShift Pipelines. We are allowing users to, let's say, create, run, manage, and do anything around the cloud native applications for the CI and CD infrastructure. The support for OpenShift Pipelines is just not on your developer console. It's also there available on your ID extensions. So in the beginning when I mentioned ID extensions, I mentioned about OpenShift. I mentioned about serverless functions. We also have the same workflow around OpenShift Pipelines available on Visual Studio Code and IntelliJ. And if you have heard about me, I'm mentioning a lot around Visual Studio Code and IntelliJ. The reason behind it, there was a survey which happened from Stack Overflow for 2022, and they figured out the number of developers using the ID, the VS Code ranks at the top, approximately around 60%. Then slowly coming down, they have multiple other IDs, and IntelliJ also ranks around there. So from Red Hat, what we are targeting is we target, we want to reach where the developers are. So if the developers are using Visual Studio Code and IntelliJ, we want to provide them the toolkit what we have. And the same goes for pipelines. After my session, we have Ritesh on stage, and he will be detailing more on what we do for pipelines, what we do for GitOps, and ML other frameworks. Now this is what he's going to do more on, so I'll let him do the talking so that he can give you a much better perspective. But this is something around the roadmap, what we do at Red Hat. Okay, the next big thing what we have coming down the line is apps to do. The important part of what we wanted to fix was the key challenge here is to develop and deliver, enterprise get cloud native applications, right? And it should be across cloud platforms. When I say across cloud platforms, you understand that it means multiple other vendors like Azure, GCP, AWS. And this is something which is currently in development, which is still in preview, and if you want to read more about it, we have the URL there. And the important part of it is it will be a very abstracted end-to-end experience. So it will be basically reducing your complexity, reducing you to understand what the technology is, what architecture is, you don't have to worry about it. You have your code, you have your code on GitHub, you just have to deploy, the pipelines will be done, the monitoring will be done, observability will be done, and every security GitOps will be automatically configured using this UI. So this will be a graphical interface and which will be releasing out soon. So I think this is what we had for the roadmap, right? So I have not gone a detail into it, I just wanted to keep a very overview of it so that if you guys have any specific questions that, okay, what Red Hat is doing around roadmap, you should be easier to understand. This is a bit summary that what we exactly do, right? So let's say we want to keep it very simple, very open-headed, that, okay, I just want to code and I have my code running on my ID. Can I deploy it on a cloud-based browser? Yes, you can do it. Can I run it on a web terminal? Yes, you can do it. Okay, but I want to do it on my ID itself, so we have plugins for that too. Now, when you say continuous delivery, right? You have the CI-CD support, you have the Argo-CD support, and we also are trying to make sure that observability, monitoring, everything is working out of the box. And this is something which is centric around more and on OpenShift, where you can code, debug, and deploy and very easy interfaces. So that's what concludes my session for the roadmap, right? And we are available on Twitter on Red Hat Developers. The next one is, my name is Mohit Suman, so you can reach out to me on Twitter if you have any specific questions around it. I look after around all the ID extensions across Visual Studio Code, IntelliJ, and even Eclipse. That's it, what I had for it, and if you have any specific questions, I think I have some time left. Do you mind going to the first slide where you had inner and outer loop? So you've been mentioning there's a 30-day trial period, so it leaves me to assume there is some cost after that, right, for using OpenShift. No, no, so basically this is for you for onboarding your developer experience, right? Let's say, if you want to, you're comfortable with that, right? And you want to deploy another instance, you can still do that another instance. But at one point, it will be a paid version. No, so let's say your instance, 30 days is done, right? You can again go to your website browser and you can again provision a new cluster. So there's no charge for it, I can recurring basis, I can keep running it. That's basically a- It's not sandbox on a proper enterprise setup, they're correct. So if that is charged, what I wanted to know is in the inner loop when we are writing code and when we are building it, for it to get built, it should run somewhere, right? And OpenShift cluster is probably where it is running, right? So it is, OpenShift cluster should also be based on some cloud, right? So what I want to know is, is it running in your, let's say AWS for example, is it running in Red Hat's AWS account or is it running in my company's AWS account? Yeah, so if you want to run on a cloud, right? Let's say you just want to run an OpenShift. So that OpenShift can be on bare metal also. It should not be running on AWS on OpenShift on AWS. It can be just OpenShift. But if you want to run OpenShift on AWS, that's also allowed. OpenShift on GCP, that's also fine. When you say your company, if you provide the credentials of your account of AWS, that can also work there. No, but that way I will be paying for the resources in AWS and I will be paying for OpenShift, like enterprise cluster, right? So it's twice the price. No, no, that's not twice the price. That will be OpenShift on AWS support. So you have to pay only for the OpenShift AWS support. So there's a partnership between Red Hat OpenShift and AWS. The same way there's a partnership with Red Hat and GCP. So you as a customer have to only worry about one place. And that will be managed from Red Hat team to make sure that your cluster is always up, there's no downtime, or whatever customer support you need around that. So that will be Red Hat's headache, not yours. Okay, so in inner loop, let's say I'm running it on bare metal, like you said. So I am paying only whatever is the cost for using OpenShift clusters. So that's one point where I'm paying. After that, it goes to the outer loop and then it goes to production. And if I use one of those clouds, I will also have to pay there. No, no, so the idea of inner loop is, so let's say I as a developer, right? I want my Node.js application to be running on AWS cluster. That's my end goal, right? But before that, I need to test, right? Whether that will work on, I cannot test on a production system. I need to test on my local system. So when I say that, so there the advantage of onboarding comes. You have a 30 days provision of a sandbox. You quickly connect to it. You just test multiple scenarios around it. You see, oh, my everything is running. My CI CD is working fine. My code is getting deployed fine. You are happy with it, and then you move to the production. It's not that every time you have to do a build on production, because then it definitely will scale up your expenses, right? So once you're good with your inner loop, outer loop, you move to production. So the onboarding helps you to do this continuous development iteration over it, because it's just not one developer, right? Let's say a team has 10 developers. So you cannot have 10 production instances, right? You will have only one production instance, but you will have 10 different onboarding instance, which you can continuously do for deployment and move forward. Okay, got it. Thank you. It's more related to that actually. So inner loop is typically done on OpenShift local or it can be done on the, with any bare metal OpenShift cluster as well. No, any bare metal. So the idea is you need to have an OpenShift cluster. So that can be an OpenShift local, that can be developed by Sandbox, or let's say you also have your own provision cluster somewhere running, right? That also works. The idea is the inner loop should be connected to a cluster. Okay, that's the whole point. So let's say you have your somewhere running on Docker, right? That also works. If you're running on Podman, that also works. It's basically allowing you to continuously do this inner loop cycle, any of the provisions of this code build and deploy. So it should not be that, okay, my OpenShift should be local. No, you just need to connect to an OpenShift instance. So for inner loop, you have a plethora of tools. So it's for outer loop, right? So if you want to say, I have my own IDE, I'm just using extension, then you use the IDE extension. If you say, no, I just want an hosted IDE. I just go code, close my browser and come back, then you have DevSpaces. So it depends on what you choose. Charge it. And then eventually deploy on your production. I see you mentioned about Podman desktop and Docker desktop. So basically I wanted to know, is there any recommendation or suggestions when one should go with Podman desktop or Docker desktop? We don't, we are not partial on any of them, but it's up on your developer choice, right? If you, let's say you are comfortable with Docker desktop, right? And you want to be there, you can still go ahead and do on Docker desktop. But the challenge with Docker desktop right now is, they are charging a fees for using it, right? But Podman desktop is free. So if you want that, you can go ahead and do with Podman desktop. And the advantage of Podman desktop is, it's been built by the Red Hat team. So let's say down the line, if you have any specific bugs or something around Podman desktop, you can definitely reach out to us. It's an open source project. If you have any problem, it can be fixed and it's supported by Red Hat. So from our recommendation, I would say Podman desktop would be the ideal workflow to work with OpenShift or Kubernetes, whatever you want to work with. If you want to use any enterprise applications, right? Kind of like IIB and Oracle products and OpenShift, what is the process to onboard them? So if you go to cloud.redhat.com, right? There are multiple ways you can provision your OpenShift engine. So thank you for asking this question. So I think I have time, so I'll go through it quickly. So if you go cloud.redhat.com, basically you need to log into the console, right? If you don't have an account, you can just simply go ahead and create an account. Once you are done there, you will see multiple options where you can provision your OpenShift instance, which can run on AWS, GCP, IBM cloud, multiple bare metals instance. So everything is provided there and that is basically a guided workflow. You just have, let's see if AWS, if you want to do, you just provide your credentials there and it will start your OpenShift on AWS. And next question is what exactly difference between OpenShift and OpenShift container platform? OCP is also there, right? So there's no difference between OpenShift container platform. Yes, basically OpenShift is an enterprise Kubernetes, right? So that's the OpenShift container platform. So last thing that I would like to showcase is this is something which Red Hat has been working, supporting multiple extensions, which we have on VS Code Marketplace. If you see these are number of extensions we have and this list will be continuously increased, giving multiple support around multiple technologies. So this is one of the important roadmap what we have with respect to developer tools. If you have any other questions, please feel free to ping me on Twitter or chat me outside. I will be very glad to do it. And thank you for your time. It was really nice talking to you guys and thanks for all the questions we had. So see you soon, bye-bye, thank you.