 You see here the current production version of the Red Hat CoolStore, an example microservice-based e-commerce app containing multiple cool items. So we want to show a real-world application example such as an e-commerce to demonstrate how Overshift platform nicely connects the development phase, the so-called inner loop where developers code, build, test, and ship artifacts packages inside the platform to the release deployment phase, the so-called outer loop where CICD happens with secure pipelines and GitOps-driven multi-cloud deployments. And it looks like we're running out of Fedora here, so we take this as an opportunity to show how to bring a new feature from development to production with the Overshift platform. In order to do that, we're going to add a new quantity of Fedoras from the CoolStore inventory service. And so to do that, let's start with the inner loop. For this demo, we created an example organization, the Red Hat CoolStore, and we store our repository on GitOps. As you can see, those are the repositories that represent the microservices for this application. We want to enable and onboard developers on this project. And Overshift has an excellent support for mapping users and groups from multiple identity providers, such as GitHub. As a developer, once I log in into the Overshift platform, I'm onboarded into the Overshift web console experience. In this experience, I can self-serve to discover and scaffold templates or application from the developer catalog. Those could be pre-built or also fulfilled afterwards with customization. In addition to that, Overshift web console experience offers also developer onboarding on project and answered with QuickStart. So the QuickStart are guided path to project setup and enablement, and those are pre-built or can be also customized. In fact, for this demo, we created a specific one to onboard developers on the CoolStore app development. The QuickStart will cast through the project representing the application development environment. And within this project, we can review all the services running from the topology view. The topology view show all the services and for each service, we have a list of all the details, such as the status of the app, the health of the application, the resource consumption, and a list of application running, internal and external networking. And so we have an enhanced support for development and production telemetry with native monitoring and observability. For each service, we can go looking our resource consumption in terms of CPU, memory, RAM, storage, bandwidth. We can go granularly into a time range selection, but also we can set up a custom metrics or alert and we can have a list of all events happening for this service. In addition to that, for each service, we can review the logs of the application and this log can be in single instance or can be provided in some aggregated form. Obershift provide also support for editing code. And watching also our quick start, we can also start editing our service directly from the topology view. So Obershift support the support for editing and coding with an in-browser IDE systems called Dev Spaces. Dev Spaces is a system that creates a development environment inside the platform called Workspace. The workspace can be created starting from a list of workspace already available from the platform or they can be customized as convenience. In this case, we have for instance, workspace definition through a file called the Dev file. So what we have to do is just click from this user experience on this action from in order to edit the source code or we can have the same experience by calling this API from another source point. But once we invoke this action, Dev Spaces will start creating our workspace on how we need it and the workspace will start with an overview and a get started view of action we can do. In this case, this is Visual Studio Code with all our setting that we need. In this case, this is a Java service and we're able to program the workspace through the Dev file definition. The file is an open standard interoperable that can be used to start the workspaces into multiple environments. And the good thing is that you can pre-fulfill action like building a testing or running the continuous testing mode. In order to do our change, we can start editing our Java code. There's great support for runtime languages into the Dev space. And for this specific use case, we can start editing our code. Say we don't want zero quantity, we want 100 quantity into the inventory. We also update our tests because from the Dev spaces, we can start running our unit tests. So we can ensure that our software tested within the interloop before kicking off the outer loop and the pipelines, we can make sure that our software is tested and it's good to go. Dev spaces also provide a really nice feature which is the networking feature. So it can expose these microservice from the outside of the workspace. So the developer can share their application to other developers and to check if everything is fine. As you can see, in this case, our Fedoras have been increased to 100 quantity. So we're good to go in terms of coding and testing locally. But before we go and we kick off the outer loop is also good to take a look of the extension availability into the IDE. For this specific case, we stole this extension, the dependency analytics extension created by Red Hat in collaboration with SNCC which is able to perform vulnerability scan to the software dependencies in the app. So before we start everything, we can perform such vulnerability scan and from our dependency file, it depends on the programming language. In this case, in our POM file, we run the dependency analytics and it generate a report that we can consult locally and this report can give us a list of a known vulnerability with all the details available in this case through our partners, Nick. But as you can see here, we don't have any direct vulnerability. So in this case, it looks like we're ready to go. We're ready to push our change and increase the quantity of Fedora's in the store. So we just review that our tests are up to date and the continuous testing mode validated that. So our tests are good to go, they're fine. And also we can review our search code update and if everything is fine, we can just commit everything and push everything. So we just provide a comment for that, like update the inventory quantity for Fedora's to 100. That looks good to go. We can push our changes into it and this action will kick off the outer loop. So we have seen how we could and board into the Obershift platform start watching our development environment, checking and monitoring of the observability logs and start our development phase and start coding and testing our change before we push to get.