 Hi, I'm Michael Ducey, Senior Manager of Managed OpenShift Black Belt here at Red Hat. And with me today is Narav. Hi, my name is Nirav Doshi and I'm part of Managed OpenShift Black Belt team. And today we are going to talk about Trend Hat OpenShift Dev Spaces. So Narav, we talk a lot about how we enable developers to move faster and ship code faster and increase developer velocity. What are some of the ways that we can do that with OpenShift application platform and OpenShift Dev Spaces? So yeah, so as you know, like we have managed OpenShift application platform, which is a turnkey platform. And basically it serves two different personas, right? It is the developer and it is an ID ops. So from a developer standpoint, we provide all the tooling that's required to build the application. And from an ID ops perspective, it's basically we take care of the infrastructure so they don't have to worry about the infrastructure portion of it. Right. So as we think about developers and the concerns of a developer, developers have kind of this what we call the inner development loop cycle, right? So they'll code a new feature. Then once they've coded it, they think it works. They'll do some sort of validation or hopefully doing some sort of unit testing. And then they'll debug their code because we always think it works right the first time, but it doesn't. And then they'll go through the process of refactoring. So how can we kind of take this process and kind of encapsulate it inside of Red Hat OpenShift? So this is basically the inner loop where a developer is very focused on basically writing codes. They don't care about what the infrastructure is. And this is where the dev space. So the dev space sits within managed open shirts. So that's where basically the dev space sits in. And when you think about it, the developer has worked on their code. It works awesome. But then they need to commit to the repository. And once they commit to the repository, it goes through the CI-CD pipeline and then I would call that the outer loop. And that's where they would basically publish their code and test it and then deploy it. So from a dev space perspective, basically what we provide is when you think about some of the challenges that companies face. So developers, if your company has a lot of developers, then they have a lot of resources that are tied up. If they code on their machines. Yeah, and for a lot of people, this is usually done on their laptop. Yeah. So then sometimes that code is not secure to the standards. And it's just lying on somebody's laptop. And then the third and foremost thing is many a times you have heard of what are between developers and IT ops in terms of like the developer says that my code works on my machine. But as soon as you move it to production, it is like there's something off. Right. We're at the same deal. Yeah. But so that's why what we are doing is we are taking the development process more towards the production. And that that's the way basically you can debug any issues that come early on. OK, so walk me through this in practice. So what are the IT ops people need to do to enable this? So they've installed the operator, the DevSpaces operator. And then what are the steps there and then how do developers consume it and use it? Yeah. So from an IT ops perspective, they will install our DevSpace operator. And they will provide all the CLIs, the binaries that are used, and the libraries that are required for the developer. So basically the tool chain? All the tool chain. And then from a developer standpoint, for example, if they define that they needed to build a Node.js application or they have a particular IDE in mind, they can basically use that to spin up a container within the managed OpenShift platform. And so what's running inside of that container? So inside of that container, basically you have the pods with the Node.js application. You also have the IDE that you want to provision. And basically you can use that as a workspace. So this is your workspace, predefined workspace that you can work on, build your code, and then you can share it on with other developers. So that way it's a centralized repository of what you build. So all the work moves off of the developer's laptop and into our cluster where we know there's security, compliance. We know where the code is going to be stored. It's not going to be taken off of someone's laptop and moved around or anything like that. So all the development work is done here. So I'm a developer, right? And so I went through this cycle. I got the feature ready. Now I'm ready to share it with other people and get further feedback and testing. So usually what that, what we call the outer loop looks like is the developer's going to commit their code. And then that'll go through some sort of a build process, which is usually our CI CD or our CI continuous integration system. It'll go through some sort of testing, which is when we start getting into our CD pipeline. And then we'll eventually go and deploy this application out. And then of course, the cycle repeats itself, right? So how, what other tooling do we have besides, so this is a neat idea where we can develop, but now I actually have to push this into production. And I guess the other thing that I would say about this is through the cycle, is I don't have any backing services. So a lot of applications are dependent upon backing services. So before we talk about this commit, how can I actually test against those backing services? So I know more likely that this test will pass. Yeah. So basically you can deploy additional containers to all the different services that you need. And like, so for example, if you need a back end service or you need to have a database that you want, you can basically deploy containers and test it out there. And that's the way basically once those are there, you can push it to get and commit your. So I'm using known versions of those services that I know they're actually probably running in production and I can run my test workloads against those particular back end services. Okay, so which test is against our back end services? We're ready to commit our code and we've committed it up. So how can we help with this kind of algorithm loop cycle? So besides the dev spaces, we also have something called OpenShift Pipeline operator. Basically that will help you to build images, right? And then from there, you also have a GitOps operator. So what you can do is basically the pipelines will basically create the image, push it to a repository and create a container. Whereas with GitOps, what it will do is it will basically detect the changes and update the manifest and push a newer version. So if you have the version two, you can push another version of it and that's the way it would detect all those changes. Okay, so I do the commit in to Git and then this commit fires a webhook into pipelines, right? Then it's going to build my image, put it in the container registry. GitOps actually deploys that image out, but now I've got two versions of my code. How can I control the traffic? Because a lot of organizations like to do is they like to do some sort of blue-green deployment where you've got two versions of the application. You send 20% of the traffic in one direction, you send 80% to the other, and you get some validation whether the application is going to work or not. Yeah, so that's where we have another operator called ServiceMesh, where you can basically control the traffic and basically just control the traffic. And with GitOps actions, you can basically send 20% of the traffic here and test your code as well as 80% of the traffic here. So basically that's another operator that's all built within the Managed OpenShift platform. So there are a lot of things that the developers can basically use within the platform itself, and then they don't have to build it on the other level. I'm worried about all the HUD and I think also from an ITOps perspective, usually piecing all of this together takes a lot of work as well. So having the ability to deploy these operators and really turn on the application platform for developers can be really, really powerful through ITOps teams as well. That's right. Thanks so much for coming and talking to us today about OpenShift DevSpaces in Arav. Thank you for watching as well. If you want any more information about Red Hat's products or services, visit our website, of course, at redhat.com.