 So, good evening, everyone. I'm Mohit Suman. I work as a senior product manager at Red Hat Managing Developer Tools. I had a session just after lunch, so I'm hoping if folks were there, nothing new to see me on the stage, but for folks who have joined now, welcome to the conference, and I hope you have liked whatever we have till now. This is the last session for the day, and I will try to keep it as quick as possible, making you less sleepy and avoid Bangalore traffic. So, let's get started what we have. The idea of this session is more around the demo, what we are going to showcase you and less on the slides, but I've kept the slides a bit informative so that you guys, if you have any questions, feel free to ask after the talk or maybe between the talk, but let's jump deep dive into it. So, the session of the talk is Developer Experience for OpenShift and serverless, and I will be focusing how you can do through ID extensions, and the main focus will be right now on Visual Studio Code. Can I just have a hands up, how many users here are for VS Code? I'm assuming majority of them, so great. So, I think you guys might like this. So, going forward, if you go to cloud.redhat.com, and these are the cloud providers we support through OpenShift, right? You can run OpenShift on AWS, Azure, Google Cloud. You can see redhat.coded containers, but that was the original name for OpenShift Local, and now it's known as just OpenShift Local. Now, who was it all for? Like, why do we need to do this? And this is specifically for these type of people. The developers are the real king makers here, right? We want to empower you guys, make sure that your experience allow development around any technology. It's just not specific to one tech, any tech stack you use, you should be the king makers, you should decide where your application is going to be deployed. Now, the main focus here is OpenShift and Visual Studio Code. It's about the developers to increase the productivity, to increase the efficiency, and to make sure whatever preference you have. Let's say if you have a preference around working with just your local system, that should work. If your preference around any specific cloud provider, that should work. And if you have a preference, no, I just want to deploy my .NET applications. I don't know Java, I don't know Node.js, but I know .NET. That should also work out of the box. And this is just one example, right? Now, the main important factor of using an ID extension here is, you need not worry about updating your clusters anytime, cell service deployment, or cluster node scaling. Your idea of as a developer is just to code. That's your task. Your task is not to worry about all these specific infrastructure or let me rephrase it as admin structs, right? Your task is deploy your application, select language runtime, the universal base image wherever you want to deploy to, and any platform. And by any platform, I am referring to Beat Windows, Mac, or any Linux version. Now, the main advantage here is, developers who are quickly deploying and developing their applications, which basically means, if you as a developer are empowered, your business value is going to increase, right? You can say and go back to your team to say, oh, my .NET application can run on any cloud provider. My Java application, which has monolith of course, I may even build everything, works out of the box directly from my ID. I need not know any CLI tool. I need not know any Kubernetes configuration. I just need to know my technology stack and that's it. And your code is going to be deployed, improving your efficiency, your company's business value, and everything together. Now, the advantage is everything what code needs is there in your ID, right? The code is there on GitHub. You deploy that on your ID and boom, and you get started with extensions. The advantage is as soon as you make any code changes, the push will happen, the builds and deployment conflicts which are needed for Kubernetes, people who are aware of Kubernetes infrastructure will get it. And let's say whatever deployment happens, right? You want to view the logs, you want to stream the logs, what's the error? Because let's be honest here, nothing works at the first instance. Something or the other is definitely going to break. But when it is broken, right? You need to view the logs, you need to follow the logs and you need to know what has broken, right? And Kubernetes sometimes can be overwhelming. So you need to know exactly which part is down. Do I need to check my build conflicts? Do I need to check my deployment conflicts? Everything is done through the ID. You are not leaving your ID any time of the work. You need not consult your ops team. Oh my God, this is broken. Can you fix it? No. You as a developer can do it on your own. So it's more than that. It's just not writing your Python code. It's more than that. And I'll go ahead and say that deploy anything any time, anywhere. So that's the motto we have. I'm going to demo more on that. So this is what I had for the slides. Quick one, basically, because let's focus more on the demo side of things. But the idea here is we are working on creating extensions specifically on Visual Studio Code, also on the IntelliJ. The features which are there on VS Code will also be there on the IntelliJ side. Let's say you as a Java developer, right? And you are more comfortable with IntelliJ. And you don't want to use VS Code, but you'll have the same level of functionality there on VS Code and IntelliJ together. Now, when I say using the best breed of tools, so throughout the day, you might have seen people speaking about OpenShift Local, developer Sandbox, developer Console, Odo, multiple tools what Red Hat provides, right? So you might be thinking, oh, I need to know everything where I will find and all XYZ stuff, right? That's always there on developers.redhat.com. But if you use the ID extensions, all these tools are directly available on your ID extensions. So let's say you are comfortable with any specific tool, what we demoed today. You can still do that with the same set of tools using the extensions. The extensions are available on Marketplace. It's just one click download, and it have approximately more than 50,000 of installs. It's an open source project, and we have community involvement coming from Ractal, coming from Microsoft, and Red Hat who are together building it and making it sure that it works for all the cloud providers, right? And it's just not this, that's okay, you can just work with OpenShift. There are multiple extensions which Red Hat provides, which I will be going here. So if you go to VS Code Marketplace, so this is the link, just go to Marketplace.com Visual Studio. This is the name of the extension what I'm talking about. We did one dot GA release just yesterday which supports the latest workflows which we'll be demoing. And if you go to whatever extensions Red Hat supports, these are number of extensions we have, and OpenShift toolkit extension integrates a lot of them. So if you see, let's say you are a Java developer, right? We have a Java extension which has approximately 19.6 million of installs, which is a very high number. So let's say out of those installs we have a very active community around Java. That integration also works out of box. So if you have a Java application in your code base, you just have to do one right click, deploy to OpenShift, and that will be directly done through the ID. So let's quickly jump into the extension demo here. Okay, so if you go to extension stab, this is the Visual Studio code. I'm assuming this font size and the screen color is easier for you to look, right? Let me know if something is not working for you guys. So if you go to the extension Marketplace and you just type OpenShift, this will be the extension which pops up, right? This is already installed in my system, just for the demo, so I'm not going there. Now let's come back to the OpenShift one. So OpenShift extension right now has three different type of views. The first one is known as Application Explorer. This is basically the view which shows you what type of connection you already have, right? Are you connected to a cluster? If you're not connected to a cluster, the first thing you see, this is a default Kube config. If you're a Kubernetes user, you will already be aware of it. So if you click on it, it basically opens your Kube config directly in your editor itself. So let's say if you want to edit your Kube config, you don't have to go to command line and do x, y, that stuff. It's there in an ID only. And if you see here, there are two contexts which are added. One is the Kubernetes context here and the other one is the Sandbox context which I've already added. So my Kube config already has the information where I need to log into, right? If I don't have, I can just log out or maybe change the context. I've logged in just for the demo purpose. Let's say I'm a new user and I don't have any access to OpenShift. I need to provision one. So if you do add OpenShift cluster, it will open you a view where you can create, this will create an OpenShift local directly from ID. If you click on it, you see this is the guided workflow which we have. You just to provide some of the informations and that's it. You can just start with your development with OpenShift local. Now, if you don't want that, but you want, I need to know developer sandbox. So either you can do developer sandbox directly from here, log into Red Hat, do it, or you want to do it through the browser. You can just go and learn more and this will basically open up your browser instance which I'm assuming should work. Okay. So this is the instance of developer sandbox. You see, I'm already logged into my sandbox instance so it will say, oh, it's start using your sandbox. And this is the same cluster which I'm connected to my VS code instance. You see here? Now, once I'm connected to this and let's say I want to log out here and I want to log into a new OpenShift instance, right? I have my own OpenShift on AWS. I can do that too. Which I'll be showcasing you how to do the switch context later on. But if you go here, there's a switch context. So let's say I already have Kubernetes running on my Docker system. So this is an OpenShift instance. This extension will also work out of the box of Kubernetes. So let's try out that. I switch my context. Cluster context is switched. Sorry for it, it's very small for you guys but this is what you can see. And as soon as you go to the application explorer, you see the context is already changed. So this way you can switch between any Kubernetes context which you are already logged into. So let's say you have an application which you want to test on multiple clusters. Just switch context, deploy your app and boom, you are ready to do everything. And if you see, I'm not leaving my editor any time during the demo. So that should be great. So I have a .NET application in my workspace. So me as a developer, I'm working on my .NET application. This is a .NET application. I'm hoping some of the folks are aware if it .NET or C sharp. I would have showcased demo around no or Python but I think my Red Hat folks have already done something around those technologies. I'm focusing more on .NET here. So I already have a Docker file here. This is something which we want to deploy. And if I go to OpenShift instance, and I already have a component here, I just have to start dev. What does start dev means? It will start deploying this application locally on this Kubernetes cluster. So before we start to do that, let me just showcase you this. So this is my Docker instance. So if you see here, nothing is running as of now. This was four minutes ago, which was a bit longer time. Let's do this. .NET app, start dev. This will open up a terminal. It says it's waiting for Kubernetes resource, right? Now let's go to Docker and see what happens here. As soon as the resource will be created, you will see some configuration which adds to the Docker instance. So now what happens due to internet, this might be slow, but what is happening here is this .NET application is getting deployed using a specific deployment configuration which is known as a dev file to this Kubernetes cluster. Let's keep our fingers crossed that it should go out and work. Meanwhile, what I will showcase you is you have a GitHub repository, right? Every code resides on GitHub. Let's say open source code resides on GitHub. So let's go to browser and search for a Node.js project. Okay, I already have it. So I want to deploy this Node.js project on OpenShift directly from GitHub. Nothing else, right? I just copy paste the URL. I go to my OpenShift extension. I do import from Git. I'll mean by closest terminal. So I just need to provide the URL, that's it. What my extension does is it basically scans through my GitHub repository on the fly and which figures out, oh, my code was Node.js. So this is the specific deployment file which I should use. If I want to do something else, I can anytime edit it, but for now, this is a deployment file. This will be the name of the application. This will be the name of the component. If I want to change, let's say I change it to one, two, that's for unique. And I say create component. Now when I say create component, it basically asks me what should be the workspace where it adds in the VS code instance. So let's say I do this and I say demo dev and I create and add this. Now what happens is if you see, it creates this component here, this one, and it's creating that component. Wow, the component is created and your component view here is updated, right? So basically, this component is there on your local system. Now the next task is, let's deploy this on OpenShift. Let's see what happened to the .NET one. So we have showed dev terminal which is the terminal which has opened up. Okay, so there is some error here, but we should be good. So what we should do here is, so this is the live demo. So I am just keeping my fingers crossed that something might break, the curse of demos, but let's do stop dev for now. And this one, if I do start dev. So the idea is you can do multiple deployments on your Kubernetes cluster, right? This should also work on it, I'm not sure, but let's see. So let this be preserved. So meanwhile, this is running. So I have shown you two things. One, you can deploy your folder which is there in a workspace directly. The second, you can deploy directly from a gate repository. The third one is, let's say you don't even have a gate repository project, but you want to work with, let's say with Python, you want to just explore it, right? So what you do is, you go here and you click on this. This basically opens you a DevFile registry and this is the list of templates or stacks provided by the DevFile community. So when I say DevFile community, this is community which is supported by Red Hat, JetBrains, Amazon, Microsoft. So all these companies together are working to create a basic template so that deployment on any Kubernetes platform is easier. So you follow one set of template guidelines and these are the list of components which are there. So let's say I have multiple lists, right? But I want to do, okay, let's say what? Let's say Quarkus, the first one. So I just click on this. What it saves me is, okay, these are the two stuffs where I can start. One will be a community project and one will be the Quarkus which Red Hat provides. So let's say here you can see the DevFile. Due to the white theme, the colors are not matching, but this is the DevFile what we have. So this DevFile will get created. So let's say new component, the same way it asks me the workspace folder. I say this and I say then, I say the name is Quarkdev, the project name it asks. So let's me, it's still pending. So let's do that. So as soon as the component gets created, the component view gets updated as soon as that. And if you go to workspace also, you will see those components are already there in your workspace. So it's that simple that with one click, you will have these applications done. So let's go back to this. I think there is some weird error with my Kubernetes. So let me switch context again to Sandbox. Hopefully Sandbox should work. But the idea here is we are providing users with different ways you can create your component and deploy an OpenShift. That's the whole idea here. Either do through workspace or do through the standard templates what we provide. Now there might be a question that, okay, why should I always use the default registry? If I have a registry on my own, let's say my company supports only four type of languages with all the security protocols and everything. And I want to use that registry. Let's say it's an air-gapped environment or a specific environment working for banks or somewhere like that, right? So here you can go ahead and just click here. This basically will ask, provide your registry URL. So as soon as you provide your registry URL, so let's do some random demo and do this. And just add this one. Meanwhile, I just start this. But if you go here and add the registry name, this will basically add a new registry. So you can start working on that registry. So your registry only had .NET, with all the security compliances, you deploy that .NET application directly on this. Okay, so the good thing is, the OpenShift instance is working. So now you can see, waiting for Kubernetes resources, adding those components which are there, the def file. And hopefully this will go. Now if you see down line, right, this is something which is, as I mentioned, all the extensions are interconnected, right? So I already have a Java extension. So as soon as you open a Java workspace in the extension, the Java extension will detect, okay, you have a Java workspace. So that will also recommend certain scenarios with Java auto-intelligence, auto-sensing, and file manipulation, everything. So you have the benefit of working with that too. So now the pod is running, and hopefully it will get deployed somewhere. So this is directly getting on the OpenShift instance. So now if you go here, the developer sandbox has the default project. And if you see, syncing the files into the container. So you see this app is already here on my OpenShift instance. Now if I open this console dashboard, so this will open up the developer console in browser. It will say open, and I go to topology view. And I select, so if you see my project name was msuman-dev, if you go to instance, you see msuman-dev is the project name. Okay, so my code is already deployed, right? You can see there are two ports here, 8080 and 555. So there are two ports which basically means the first port is where the container is running, but let's say you also want to live debug your application on top of OpenShift, not debugging locally, it's debugging on top of your OpenShift cluster. So this is the port where you have to run so that the debug will work. So now my instance is running, so if I right click on this, you can see I can see the logs, I can even follow the logs. I can open this in browser and I can also debug. What happens when I say reveal in explorer? Reveal in explorer means if I click on this, it will basically tell me where my code is there in my VS code workspace. Now let's see what happens if I show log, right? It will basically open up a terminal and it will showcase what current logs are going on. You also have an option of going to VS code setting and opening this logs directly on your VS code editor, but let's say as a developer, we prefer more on the command line side, so for the demo, I've kept it for the command line. Meanwhile, the developer console might have opened up. If you see, these were the two applications which we had deployed. And this, so within your ID, you created a component from a defile registry, deployed an OpenShift, you have a debug port active and you can see the same application running on developer console. And the same logs which can be seen on developer console with the same logs which you saw on the ID side. So you as a user are not leaving your ID and doing everything from there. Now, let's go back to the extension again and see whether the app looks good or not. So as soon as you open in browser, it will ask which port needs to be opened up, right? So let's try to see for 8080, keeping the fingers crossed that it runs something, but it works. So now, within few clicks, you have a Quarkus application deployed on OpenShift and it's running. And let's say if you want to see, so what does follow log mean? The follow log means whatever changes we make, that will automatically be synced to the logs. Let's close this terminal and see some other stuff. So, now it says that watching the changes in the current directory, right? Let's go to this directory and make some changes, a quick one. I think I am writing right. Let's see. As soon as I save, this should fetch those changes and it will start. As soon as I save, you see waiting for Kubernetes resources. So basically it detected some changes, right? And you see the local changes application on the cluster. So it's not locally, it's running on your cluster itself. So you as a developer are already checking that your application, how will it behave when it's deployed on a production system? So let's say something breaks, you are aware of it beforehand rather than going into production, breaking it and again coming back, fixing it again going back. So this basically improves your inner loop experience. You do your code, you commit your code, work with all the changes. When you are good with it, then you move to the outer loop and then from there you move to the production instance. Okay, so I am assuming it is done. So let's try to open in browser again. It will still ask me the port and I'll say 8080. Let's hope the changes have taken place, but here I had it, I have no idea. Somewhere it might, okay, it's still running I guess. Okay, it's syncing the files. So this is one scenario. The other scenario is if you go to a workspace, let's say this is your workspace Node.js and if you right click on it, there is already an instance which is added which says new OpenShift component. So any workspace can be deployed to OpenShift cluster. So that's the whole advantage we are providing. As soon as you install this extension, you will have this support new OpenShift component and that's it. That will be as simple as possible and to deploy your application there. So this is what I had just for the OpenShift instance. I will quickly take you through the serverless workflow, but before that we also have this debug sessions view which basically runs when you have the debug running and whatever logs and all you viewed here, like let's say this one, the same logs are here. So if you do this, that should also be the same. Any questions now? I can take a few questions and then I can move to serverless. I hope this will be helpful for you guys to work with any type of application. And this being this an open source project, we are always looking for more feedback and more community involvement. So let's say once in the external extension and you think something is broken or something you want to add as a feature, just click on this report extension issue on GitHub and this will basically open up a GitHub instance and you can just provide what things needs to be added, what things needs to be changed and we will look into it on priority. One more thing, if you go, as I mentioned, this is a demo specific to VS Code, but if you go to JetBrain's marketplace, these are the extensions what we currently support on IntelliJ, which is specific to Quarkus, Kubernetes, Tecton, and this is the OpenShift toolkit, what we demoed right now. So the same level of extensions which is there on VS Code will work on IntelliJ and you see we did a new release just yesterday for 1.0. Sorry, can you be loud? For the IntelliJ one, right? Eclipse, so Eclipse, yeah, so Eclipse tooling also supports the same workflow, but the scenario there is the workflow is mostly around OC. So right now this IntelliJ and VS Code uses Odo at the back end, which we demoed like CLI, but in the Eclipse, it's mostly around OC. It also supports Odo, but the older workflow a bit. It's not yet updated. We do the Eclipse release every quarter based on the Eclipse lifecycle release, but the philosophy of deploying your applications from repository to what should I say, the OpenShift instance is same. The challenge here is we have a lot of developers and whatever we determined from Stackover from all our users on VS Code IntelliJ. So we are doing a lot of active development on VS Code itself and IntelliJ itself, but being Red Hat, we are also supporting Eclipse workflow. So let's say if there's a customer who is using Eclipse, he will also figure out the same functionality. There might be some functionalities which are still not there, because as I mentioned, it's a six months release train, but we target that we support all the functionalities what we have here, but VS Code will always have the latest one. Let's import from Git, provide a Git URL and that's it. So that's one of the new functionalities we have which we will try to come up with the Eclipse workflow also. Great. One more thing I would just like you guys to have a look at. So if you go to console.redhat.com, OpenShift Create, these are some of the instance how you can provision an OpenShift cluster, right? So if you want to have a dedicated OpenShift instance, just go ahead and create a trial cluster. If you want something around Azure or let's say on IBM Cloud or let's say on AWS, these are some of the ways you can do it. Some of them will be paid. Some of them will have a different provisioning system. Some of them you might need to talk to a solution architect or something, but this is the landing page where you need to go and see what providers we have. Now if you go to local, this is something what we need to do with OpenShift Local. You can download the OpenShift Local version here, the pull secret. To download a pull secret, you always need to register for this cloud.redhat.com. I already am logged in, but if you are doing it for the first time, you need to log into it. It's a very simple process. Once you're logged into it, you just need to download the pull secret and that's it. It works out of box for all the three platforms. We have already seen the demos for OpenShift Local, but it also works out of the box for the ID itself. So that's the point, right? If you want to provision any OpenShift cluster, which is there on the cloud, will also work on the ID side of things because we want to make the developer not good here and there or so forget about something. It's there on our ID, that's it. And there will be documentation links and all so that you can read more about it, do more deep dive. And down the line, we are also going to integrate this. As a showcase do, we are working with Docker Desktop, right? Down the line, we are also going to integrate directly with Podman. So let's say if you want to work with Podman, you can still do the same workflow using Podman. We have not integrated that because Podman Desktop released few months back, but the next roadmap of the extension is to integrate this with Podman. So I'll quickly jump to the other extension. I don't have a lot of demos there, but I would love to talk about it just for the serverless folks to have more idea around it. The similar lines, what we have extensions for Java, Quarkus, OpenSheet, we have the same for Knative. When I say Knative, we have three different workflows what we support. One is serving, eventing, and the third is serverless functions. So this demo will be mostly around serverless functions. How can you create and deploy a function app directly from your ID? So let's go and say Knative. The same way you installed an OpenSheet extension, go to Marketplace, type Knative, and that will be there. So this has four views. The first two ones are specific to functions, which are serverless functions, and these two views are around Knative. So if someone is experienced around Knative or they want to work with serving and eventing, they can use these workflows. Right now I'm not going to demo any of them, but I will be showcasing what we can do for the functions part of it. So if you see my Kube config already had a cluster connected to, which was a sandbox cluster, so my functions extension automatically detects that, and basically it adds that namespace to my view. Right now I don't have any functions, right? So like click on this, and it basically opens a UI, a very simple UI, to create a function. So let's say I create a function as say, Bangalore, it allows me to select what type of runtime I have. So these are the supported runtimes currently, Node, Python, Quarkus, Rust, Spring Boot. So let's say for the demo I say Node, I will use cloud events at the template. So there are two types of cloud events we use, mostly HTTP and sorry, two types of template, HTTP and cloud events, and this will basically ask what should be the location where I want to create a function. So let's say I do this and I show on dev, create, and just create a function. So as soon the function is created, it will ask should I add this to a workspace or should I create a new workspace? I should add to this workspace, so that's fine. And I do a refresh. So the workspace has been updated. Go here. So meanwhile this is getting loaded, so one thing I would like you guys to have a look at, if you open this in VS code, if you are comfortable with, Command Shift P or let's say Control Shift P, whatever platform you are on, and just do get started open walkthrough. As soon as you do this, this basically opens up a guided workflow of the extensions what we have. So let's say I already have an open shift one, right? As soon as you open this, this will basically allow me to learn and understand that how the extension behaves. So let's say you as a new user are not comfortable that how this behaves. You can follow this guided workflow. And you can see first step is log into a cluster. So this will be easier. Once you're logged in, the next step is browsing all the registries you have based on that you select which component you want to deploy. Once you are done with that, the third step would be create a component. Once you're created a component, there were two ways, right? As I mentioned, either from your workspace or from a gate. If you want to do gate, you do get workflow. Once that is done, start your component development mode. This will basically create a component on cluster. Once that is done, you want to debug it. So this way, at least you can follow the getting started workflow and you should be good to start using the extension. And similar way we have for, what should I say? Soveless functions, right? So getting started workflow is something which we have added recently and that's been very promising feedback from the community because now for a new user, it's easier to work with OpenShift because now they know what needs to be done step by step, right? So that's much easier. So now the function is already here. Once the function is done, you can just do build. It will basically ask what should buy this. So instead of co-io, I will say docker.io, right? And I will say start. So what it does is it basically opens up a view in a terminal and it starts building. So basically it will build my image on docker. So hopefully this image will be updated here. I think I have last few minutes left so I'm just waiting for this to be completed. Once this build is successful, right? You see you have two other commands added which was not there previously because the component function was not built, right? As soon as the function gets built, you do run which basically is running your function on the docker instance which I did. And once that is done, deploying that function. Now once you're done with it, the next step is you also want to add some environment variables to our app, right? Because that's how people work. You want to add some environment variables. You want to add some volumes. So instead of going to command line and adding those environment variables using some CLI, the Knative CLI or function CLI, everything can be done through your ID itself. And it will open up a view. Questions will be asked. Let's say add environment variable, do you do? It will just open up a terminal and ask you a question. That's it. So and if you see the function session, it basically says my function build is currently running, right? As soon as I did, so this one is here, but let's wait for this to be completed so that I can tell you how that works. And you can directly stop your build anytime. So let's say it's running for long due to some problem. You can stop it, start it again. That's how intuitive it is. So you see the build is currently running, running, running. And if you see your docker desktop, this is the one which we ran just now. So it automatically gets created on your docker instance. This is the function which is running. And for the environment variable, as soon as I did add environment variable, it opens up a terminal. It basically asks you to select what type of environment variable you want to add or you remove. Currently, this implementation is on the terminal, but down the line we are going to add this workflow also on the view side. So the same web view which is for create function, the same you will see for adding your environment variables. Now the build is successful, so which basically is the time when we can run or deploy that, right? See this is how it is. And I think I have just few minutes left, but anyway. So if I say deploy, it basically is going to deploy that function on docker directly. I'm already connected to docker hub, so that instance will be activated and my node.js function is going to be there. So the important workflow here is if you want to start with serverless and you want to start with functions, this is the place where you can directly start with using Visual Studio Code and the same on the IntelliJ. So the target what we have for developer experience here is we want to provide a similar level of functionality on both editors. And everything on the ID makes the life easier, even for us, like we want to deploy daily some applications to do some demos. So if we have certain type of extensions for us, it becomes easier to do quick and full demonstrations, and it works for both OpenShift and Kubernetes. Supports docker right now, will be supporting Podman in the future, so covering all the bases what we have for day-to-day development workflow. So build is successful, deploy is running, and let's say if you're already connected to a tecton instance, you can also do an on cluster build, but right now I'm not connected to that, so I won't be demoing, but if you are, you can also work the same functionality. So just waiting for the K NAT for service to be ready, so which basically means I need to enable this serving and eventing scenario, and once that is done, it will be deployed. So let's say function deployed in namespace. So you see, if you cannot see, but this is the node application. So this is the very basic node application what we had, but this is something which you see with few clicks, you have a Node.js application deployed in a serverless way. That's it, you don't have to do anything, and everything is intuitive from your ID. And you have the URL, the application is there on Docker. If you go to Docker Hub, I'm sure it will be there, but I'm not opening it right now, but that's the whole idea here. You see, Mohit Suman Bangalore, this was the demo what we did, and it's there on Docker Hub. So within few minutes, you have your serverless application deployed on Docker, just using the ID extension. So you as a user did not worry about, oh, how can it works? You need to know how can it works, but you do not need entire functionality of it. You have your application directly on Docker. That will also work out of the box for Podman. And the best part here is, you can see everything from your Git repository or your workspace on your ID. So if you know what your code does, it's very easy to get deployed on any instance. So that's the whole idea of improving the developer experience. My time is up, but you have been a great audience and thank you. Any more questions, I will be very much willing to take it outside, but I'll see you guys tomorrow. So thank you again.