 Thank you everybody for attending this webinar and thanks to Linux Foundation for helping organize this. Now before I kick off the webinar, I just wanted to run some polling questions. So I will be peppering some poll questions in between as well. So I just wanted to gather some stats from all of you. So if you wouldn't mind just answering the first polling questions, so there'll be totally five of them. So please go ahead and check the polling questions and select the appropriate answer for yourself. Okay, I'll give a few seconds. Okay, looks like a majority of the people are from the Americas and then a significant size of the audience is from Europe, about 36%. So that's very good to know. Yeah, welcome from everywhere and good day to everybody. All right, so let's head in. So let's look at what we are going to cover today. Let's look at what we are going to cover today. We look at the state of our technology today, state of especially the state of DevOps and then cloud-native technologies and what are the often cited problems that is plaguing modern development teams when they're trying to address or when they're trying to use cloud-native technology in DevOps. We look at a proposed solution that we have come up with. How does it work against these problems? What is the value that we would get and what is the expected outcome? And then we go into the next layer deeper to look into its architecture, understand how exactly it works from a technical perspective and look at what is the technical stack that we would be bringing to the table to address these problems. And we'll wrap it up with a demo. We have an awesome demo. So my co-host Edward Einel is here and we'll be running through a demo of our solution framework. And of course, as always, yeah, please post your questions. We will get to them most probably at the end, but they may be in between before the demo. We may be able to get to some of the questions considering time. All right. So there is an organization called Dora. Dora stands for DevOps Research and Assessment. It is an organization that's been running the DevOps report for the last seven years. They have surveyed 32,000 professionals spread across 5,000 organizations. Again, as I mentioned over the last seven years, and they've compiled these reports. One of the primary things is today's businesses, as we all know, have embraced digital transformation both to survive and to unlock future agile operations, efficiencies and revenue streams. Increasingly DevOps is at the heart of these digital transformation projects. And so the Dora report, which is actually, which is called as the Accelerate report, it has this concept of elite teams. Elite teams are the top 20% of the teams and how they've been performing, how they've been able to leverage DevOps to achieve excellent business results. So if you look at these statistics, the elite teams, they perform 973 times more frequent code deployments than low performing teams. In addition, these elite groups have 6,570 times faster lead times, and 6,570 times again, it's the same number from the report, 6,570 times faster, time to recovery, and are one-third times less likely to see deployed code changes fail. The report has also revealed similar statistics over the last five years. So this is the latest report, this is from March 2021. But we have had very similar numbers. The trend is just going in the same fashion for the last five years, offering us very clear evidence that when development and operations teams properly adopt DevOps technologies and methodologies within their organization, they are able to substantially increase both the speed and stability of software development and deployments, the two main pillars of success within the software development life cycle. This report also examines a successful implementation of DevOps methodologies and how it affects companies' businesses. But the top 1%, so from these elite teams, the top 1% of the DevOps teams that were surveyed, they were able to meet or exceed their commercial goals 1.5 times more than the other organizations. And what this means is the productivity, the profitability, market share, customer growth, all of this have been increased by more than 1.5 times. We have had 50% higher market capital growth on average over a three-year time span than organizations whose implementation of DevOps methods have been less successful. Now if you go to another report, so this is the Kubernetes in the enterprise survey. Now today, as we all know, DevOps is almost synonymous with Kubernetes, and that's how it has become in many organizations. Almost everybody is using Kubernetes. But what we found is most of them are doing it poorly, except for the elite DevOps teams highlighted before. So organizations should not expect better business outcomes just because they're using these CloudNet technology or Kubernetes. So these numbers from this report, they emphasize that. So almost 90% are running Kubernetes, they're using Kubernetes to run all sorts of workloads, so there's not one particular workload that is not being used on Kubernetes. However, 95% of the organizations that use the CloudNet technologies have run into challenges, 95%. And 98% of the organizations they are investing or they're considering investing in Kubernetes training to address these challenges. There are 51% developers who say that building CloudNet application makes them want to find a new job, so it is causing a lot of burnout and frustration. And of course, there's 38% developers who are not able to catch up, who are not able to keep up with all these new technologies. So we understand that Kubernetes, there are many different ways of deploying Kubernetes. There are many different ways of having a Kubernetes cluster, many different ways of running applications within Kubernetes, and the technology just keeps growing. And if you add the CloudNet technology, I'm not sure how many of you have seen the landscape, the CNCF landscape, the link is down below, there are over a thousand cards. I could have put the screenshot here, but it would be so small that nobody would have been able to read what is in it. So if you add these two things, it becomes a very, very big complexity problem. So what can we do about it? We want to enable businesses to streamline delivery of hundreds of daily deployments across thousands of applications, overcoming the complexity of Kubernetes deployment at enterprise scale. So some of the problems or some of the ways that we can address these are we can enable faster deployment on development via increased automation beyond the initial stages of doing a POC, beyond the Kool-Aid, as I would call it, of Kubernetes. We want to see what else does Kubernetes not provide that we need to actually address so that it can provide an enterprise solution for today's team. We also want to address the cultural aspect of it. A big portion of this is cultural aspect and the remaining things are all engineering, as some would say. So we want to socialize data and metrics. We want to provide full scale transparency at all levels. We want to facilitate the faster decisions through making data available to everybody. We want to also measure, measure, measure. We want to quantify the velocity of change. If something's not working, we want to fail fast. We want to try something else. Developers also need to have the capability to self-serve themselves. They should not have to depend on other teams or another process. So they should be able to quickly test what their problems are. They should be able to help themselves. And finally, all this underlines is we want to remove the fear of complexity of yet another tech. And again, I'm not talking only about Kubernetes. It is all about the cloud native landscape, the thousands of technologies that are there, which makes sense. What is suitable for your particular use case? How do developers address that without spending a lot of time in understanding each of those solutions? So in effect, we want to unblock developers. We want to give them the controls back so that they are happier. They continue doing what they're doing. They're more confident in what they're doing. And we want them to be able to overcome the selection of tools, the complexity in selection of tools and its adoption. So what we have to address these things is a package solution. So we have DevOpscare. So in this particular slide, I want to showcase a new product, DevOpscare Powered Violence. So DevOpscare is a culmination of a decade of servicing thousands of customers in virtualization, DevOps, containers, and digital transformation. So we have clearly established that Kubernetes is alone not enough for most teams. There are so many other components that need to be planned, set up, configured, and maintained for an enterprise shop. Our objective is to remove the complexity involved in cloud native technologies and Kubernetes, maximize developer productivity, and handle all the operational tasks that tend to distract. With DevOpscare, we let developers focus on the bright side of development that is building world-class applications and make it a more enjoyable experience. So what is DevOpscare? At its core, DevOpscare is a fully managed service that is delivered through the award-winning Kubernetes ID called Lens and various Lens extensions. It is a packaged software-as-a-service SAS. In other words, it is a prescriptive solution that addresses the management of all aspects of the architecture of cloud native applications, running on any flavor or distribution of Kubernetes on any infrastructure anywhere. The DevOpscare solution encompasses increased collaboration via a Lens cluster-sharing feature called Spaces and Dev clusters and extensions built for Lens and Kubernetes. Additionally, DevOpscare includes an industry-grade CICD solution embracing GitOps principles, SRE, and monitoring to ensure uptime of all applications in all across all clusters, a piece of mind through continuous security and post-wire policies and an up-to-date training model. A large part of DevOpscare would be metrics-driven to ensure the changes are progressing in the right direction and at the right pace. So if you can go one step higher, one step further to understand what is the expected outcome of the DevOpscare for people adopting it. So the underlying factor, as again, I want to re-emphasize. We want to eliminate this complexity of Kubernetes and cloud native app development. We want to unblock developers and let them go. Let them create world-class applications without having these distractions. But how do we do it are these four pillars. We want to provide full-scale visibility. We want to have a single window into all aspects of cloud native development, deployment, testing, building, shipping, detect failures in deployed applications quickly, provide visibility into costs and capacity of running Kubernetes applications, provide application uptime metrics. Through automation, we want to provide a reliable software delivery pipeline through GitOps and CI CD, reduce the friction between Dev and Ops, provide validated tools and methodologies, provide enterprise-grade curated Kubernetes CNCF solutions, increase developer productivity through these mechanisms, provide guidance and solution from Kubernetes experts, have ready-made on-demand training that is constantly kept up-to-date with today's technologies, provide best practices so there is no analysis paralysis on the developer side, provide proactive maintenance through continuous metrics monitoring, provide the confidence to scale up safely and with confidence. Now all of these would directly address the unlocking ability of all these business concerns. So you want to outpace your competitors, you want to meet the demands of your customers, you want to act like a service provider, your platform becomes a product and then you want to, while you're doing all of that, you want to be able to mitigate and eliminate risk. So one aspect I want to emphasize and clarify is the scope of DevOpsCare managed service. So you can look at this sort of chart wherein you have your platform and your infra at the right bottom, this is where you would be running either bare metal servers, VMs in the cloud or what have you. You would also have your container runtime, you could have a do-it-yourself and open source Kubernetes of distribution or you could have one of the products from Red Hat or Rancher or from Rantis or it could be a public cloud provider for Kubernetes like EKS and AKS and GKE. And then if you go further up, you have the application developers who are in charge of building applications. This is the coding team, they build out code. They have configurations to make it work and they have Docker files to convert them into images and then they ship the images into registry. And then these images are used through Kubernetes or using Kubernetes to run them as application parts. Now where DevOpsCare or where DevOpsCare powered by Lensware that comes in a picture is within this blue box. So we would deploy Lens. So Lens are just like any other client. It uses Kubernetes API. It is a very popular ID as I mentioned. It has a graphical interface but it also has the capability of extending its functionality via extensions. And these extensions are what also go through the Kubernetes API and they provide super user capabilities. And through these extensions, we provide all the additional capabilities. We provide a policy enforcer. We provide a secure R-back visualization of that and making sure people are aware of what are the drawbacks of particular role-based access control models. Provide uptime of application health, capacity cost analysis, proactive security audits and remediation. A developer experience through what are known as Dev cluster. I will have a demo of that very soon. There will be experts available 24 by seven in case you have a problem. You want to troubleshoot a particular problem in one of your environments be it in production or any non-production environment or you just want guidance. You want to just know what is the best way to approach a particular problem. So the professional services are experts available 24 by seven. We already talked about training which will be available on demand always kept up to date on Kubernetes and cloud native technologies. And all of this would be provided via the backbone of CI-CD and GitOps. So I want to re-emphasize that the blue box is the only thing that would be part of this. What that means is that it does not matter what Kubernetes flavor or distro you're using. It does not matter where you're running your applications. It could be on-prem or in the cloud or even hybrid, multi-cloud. And it also does not matter at what stage you're in. You could be a beginner. You could be just thinking about moving to Kubernetes or you could be an expert. So DevOpscare would address all these different stages of your journey. Now if we zoom up a bit and look at the technical stack that would empower all of these DevOpscare technologies. So for the Docker images themselves and the application pods we have what is known as a managed Dev cluster. This is another feature available in Lens. This allows you to set up an independent cluster for each developer in your team so that he or she can experiment whatever it is that they want to do. They want to run a Kubernetes part in a particular way. They want to run jobs. All that is possible. It also has the Docker tool chain installed. So you can run your Docker builds directly within your Dev cluster. And then you can reset it back in case you mess it up in case it's not working anymore. You can just click a button and reset it and it gets back to working again. For the policy enforcer, we bring in OPA, Open Policy Agent. We have QV scan, which allows you to visualize your role-based access control and your rules. Prometheus Grafana stack for an application health perspective. We use Goldilocks and Kubecast to provide you capacity analysis and cost analysis in case you're using multi-tenant sort of structure. We use Aqua Conf test and OPA to provide you security audits and the security audits was all the way from your parts to your images as well as to your hosts. We also have a chatbot that would be, again, deployed as an extension within a lens that would allow you to reach the DevOps care team. This is the professional service of the experts, the Kubernetes experts, that is always available from an SRE perspective, from a general tool selection perspective, guidance perspective. And we have on-demand training that we host ourselves. From a GitHub CI CD perspective, we bring in flux V2 as well as GitHub actions. Now, the key takeaway from this slide is that this is a prescriptive solution. We have decided some tools for you based on our experience, based on our analysis. And we have built extensions so that at a click of a button, you should be able to deploy all of these into your environment. Now looking at another view of the solution architecture, how it works. At the bottom, you would see the clusters. You can have n number of clusters and these can be the clusters that you, as a dev team in your organization once, they could be dev, QA test, production, whatnot. The developers on the team, they would use CubeCuttle or they would use Lens. Again, Lens is just a layer on top of CubeCuttle that gives you a graphical interface, but still depends on Kubernetes API. But you would be using Lens to access the clusters and to do all sorts of operations on top of it. Now using the Lens, the capability to share the cluster, you would share this cluster with, you can share the cluster with other teams to enable collaboration or you can share it with the DevOpsCAD team. Now the DevOpsCAD team, they would be able to access your cluster securely. It will be, so it's a secure connection via VPN or as good as VPN. And they would use Lens to come in and now they have a visibility into your cluster. Again, these are governed by tight role-based access control policies that you can set up. You have complete control over those. But the DevOpsCAD team, now they have visibility into your cluster. They can view errors, they can view warnings, they can set up alerts. They can also install extensions to make it easier for you, for the developer to conduct their business, to continue developing their applications if they want a CI CD stack that can be deployed via extensions. A marketing stack can also be deployed via extensions. At the same time, the developers, they can leverage the managed Dev cluster to do the experimentation. And this is again, this is a hosted solution on our side. The developers can access it at any time. Obviously, internet access is required to do all of this. But the managed Dev cluster provides you a full-scale Kubernetes cluster running the latest GA version of Kubernetes as well as the Docker tool chain, as I mentioned before. And you can experiment on this. You can run Docker builds. You can run even Docker compose if you wanted to do so because it has the entire Docker tool chain installed. In addition, like let's say, for one example, when the monitoring stack is set up on all your clusters, there is another intermediate or there is a centralized Prometheus cluster that we would set up that would aggregate all of the metrics from all of your individual clusters into one place. So that would provide you a place from where you can run additional analytics and telemetry. We can also plug in a Grafano or any other tools that you want as expected with Prometheus. And you can provide exporters and all sorts of stuff to provide you even more visibility. And you can take decisions based on that. Now, we still depend on open source for all of our, for most of our solutions. Some of the extensions we have built ourselves, but they also have open source technologies. So there is also a connection to Helm and GitHub. And these are, these are very, very normal connections, very typical connections that we would expect for any cloud-native project. And then I also wanted to explain one other thing. One of the core backbones of delivering our DevOpscare extensions is through GitOps. Now, GitOps is fantastic because it provides you a seamless architecture and solution to test code as well as configurations. So any of the extensions that we build or any of the tools that we bring in, we would deploy it via GitOps. And this goes to our security tools. It can be policies that we set up. Everything would be pushed via GitOps. So it gives you the same capabilities as testing your application code. So every change is observable. It is verifiable and measurable. You can also do easy rollbacks to a previous state. You'd also get secure deployments. And then you can also put in an approval process which is very lightweight, just in case you don't want things to go without any oversight into your higher environments. And it provides a very modular and two independent architecture. So that is one of our art stones on which we will be deploying the DevOps care solutions. And finally, we would enter the demo. I would like to hand it over to Edward, please. But before the demo, I wanted one more poll. Do you want to remind? Please take a minute, a second to answer another poll. Thank you very much. And Edward, over to you. Thank you Anu. Excellent presentation breaking down DevOps care and why it's valuable to the community. I will give it a couple of minutes or maybe 30 seconds actually for people to answer the polling question. And then we're going to jump into a demo of the backbone technology that allows DevOps care to work and operate for our customers, our prospects and the community themselves. I do want to thank all of you for joining us today out of your busy lives, wherever you are, whether you're in North America, Europe, APAC and so forth, maybe Antarctica. But thank you all for joining today and we will jump into the demo just as Anu ends this poll. I think we have a sizable response. 40% of the respondents say complexity has been the number one Kubernetes challenge. 43% mentioned cultural changes and development as a challenge and 17% mentioned security as a challenge, 0% mentioned storage. That is very good to hear. Very much aligned with what we see from the DevOps reports. Thank you for that. I will end the poll now. Excellent. And when you get a chance, please stop sharing your screen and then I'll be able to share mine. Perfect. Thank you, Anu. Yes, cool. Then navigate over to share my screen. OK, everyone, well, welcome. Today we will be talking about Lens and DevOps Care. Lens is the backbone technology behind DevOps Care that allows us to actually build and operate and be able to actually release and showcase this product to our prospects and community. So without further ado, this is Lens. It is a desktop application. Some of it is open source and Lens allows our users to get a full situational awareness of everything that's happening within the Kubernetes cluster with the ability to actually manage multiple Kubernetes clusters. And as Anu mentioned, any certified Kubernetes distro, whether it's Marantis Kubernetes Engine, EKS, Rancher K3S, and so forth. So what we see here at a high level is actually how our cluster is currently performing in the last hour from our CPU to the memory, the capacity, and of course, some warning messages that Lens is able to provide to us and our users to get a better understanding of what is currently happening within our Kubernetes cluster itself. I do want to mention that Lens also has a smart terminal that allows you to automatically connect to the correct context of the Kubernetes cluster that you're currently leveraging. So right now, we can see I am leveraging a mini-cube cluster. It's connected via the Kubernetes API. I'm a Q-config file. And I can switch over to this dev cluster immediately and begin to understand how this cluster is currently performing. This is the dev cluster that Anu mentioned in the presentation. It is a managed cluster hosted entirely by Marantis. And this is going to give developers direct access to a development cluster all in real time without actually having to leverage their local operating system resources on their laptop and so forth. One of the neat things behind dev cluster is actually the ability to auto-wake and auto-sleep. And what I mean by that is, if a developer is currently not leveraging the cluster, Lens and DevOpsCare will be able to detect the fact that that cluster is currently not leveraging it, not being leveraged, and it will actually be able to go to sleep. The reason why this is so beneficial is we are seeing many development teams currently wasting a ton of resources on clusters that may be living in the public cloud or running on their computers. And they're not necessarily leveraging the cluster to its full capability, but they may be paying for that cluster. So here's the dev cluster. I'm going to switch to another cluster now as well, just to be able to show the true capability behind Lens and so forth and being able to actually switch from cluster to cluster while always maintaining the correct Kubernetes API endpoint. We'll clear this. You can see it's connected here, and if I navigate back to my dev cluster, I can open the smart terminal, clear this out, QCTL version, and immediately see that it's connected to the correct context. So this is extremely neat behind Lens and DevOpsCare. When you're working with multiple Kubernetes clusters, we're really eliminating the complexity of switching from cluster to cluster while being able to ensure yourself that you're working in that correct context. So if you're ever leveraging multiple Kubernetes clusters, whether it's a proof of concept cluster, a dev cluster, a production grade cluster, Lens and DevOpsCare ensures that you're working in the correct context of that cluster, really eliminating user error and complexity when working with multiple Kubernetes clusters. So Anup definitely talked about metrics and observability, the ability to get a better understanding of everything that's happening in your Kubernetes cluster and your applications. What's so neat here is we can immediately see all of my pods that are running and some messages that are associated to this pod, giving us a better understanding of what is currently happening and showcasing and directing us on how to actually troubleshoot an error that we may see within our Kubernetes cluster or an application through DevOpsCare. Clicking into one of these pods, we're going to get a granular view of everything that's happening within this pod from the labels, the annotations, the operating system and so forth. We can see the containers it's currently interacting with and this pod is actually currently killed and that's why we don't see any metrics. So if I actually open a different pod, we are going to pull in those metrics again from CPU to memory, network and file system. If we see a drop in file system, it's extremely important that's going to let us know that we need to troubleshoot debug and so forth. Again, one neat thing behind Lens is also that it's always leveraging your role-based access control from your KubeConfig file and DevOpsCare does the same thing and we actually help you get or we actually give you the necessary details and requirements needed to ensure that you are following the best practices when it comes to role-based access control as well. On the top right-hand side of Lens, we can actually see some admin functions I can perform. Again, these admin functions are based off of your RBAC, so if you don't have the correct role-based access control from your KubeConfig file, you won't be able to perform many of these actions and we'll actually showcase this in just a couple of minutes. We can view our logs all in real time, get a better understanding of how our cluster's performing or our pod. We can download these logs and the neat thing and Anup actually mentioned this is through Lens and DevOpsCare, we actually have the ability to create secure spaces where I can share my Kubernetes cluster securely without ever exposing my KubeConfig file to a colleague. So that's really matching best practices as well from a security standpoint. And Lens Spaces again allows us to share access with colleagues, with the DevOpsCare team to ensure that we are taking care of troubleshooting issues, logs and also being able to do everything that Anup mentioned within DevOpsCare. So from here, what I'm actually going to do is I'm going to create a space. This space is what is used to actually share the cluster with a colleague and I'm going to create this space. I'm going to add my cluster to this space and actually I'm going to be able to share a local mini cube cluster that's running on my current operating system on my laptop with Anup and he's going to have admin functionality and admin privileges to that cluster. And this is exactly how DevOpsCare is going to work when the team comes in, gives you best practices, sets up the GitOps, our CICD pipeline and so forth. Cool, so I'm going to navigate to my mini cube cluster. Again, we can see everything here in one beautiful place. Actually, before I jump into that, I do want to showcase some very cool things as well. So Anup did talk about extensions and we're continuously building many, many different extensions that allows us to enable DevOpsCare for the community, our prospects, our customers and so forth in a beautiful way. So I currently have various different extensions currently added to Lens all by our partners and built by us. Here you can see cube cost, you can see Aqua Security. These are extensions that one, for example, cube cost will be able to tell me how much money I'm currently spending on my Kubernetes cluster and that environment. We have the starboard extension that's going to scan for vulnerabilities and so forth on my Kubernetes cluster. And I do want to note that we are going to showcase all of these extensions in the next webinar where we really go into depth of all of the capabilities that these extensions can provide for us on our Kubernetes cluster and through Lens Dev or DevOpsCare powered by Lens. So now let's go ahead and actually create a space. We're going to create a secure space that we can add my mini cube cluster to. This space is going to be called DevOpsCare one. Excellent, so we created this space and once we create a space we do need to add a Kubernetes cluster directly to this space. So what we'll do is we'll navigate to my mini cube cluster. I'm going to hit this plus icon. That's going to add the cluster to the team space. I do want to note that when you are adding a cluster to a team space we are downloading a Demian set directly to your cluster which actually creates a end to end encryption between your Kubernetes API endpoint and the Lens cloud API ensuring an encrypted tunnel that is happening to ensure that we're meeting best security practices. One of the reasons why we've developed this feature is because, and I think I touched on this a little bit but it's mainly because a lot of organizations need to share cube config files with their colleagues and that's not the best practice. Once you actually give somebody access to your cube config file they have access to that file always although maybe they don't have the correct role-based access control but they do have access to that cube config file and we're really potentially causing security concerns. So here what I'm going to do is I'm going to add that cluster to the space. We're going to download that Demian set that I just mentioned which is going to create that tunneling that end to end encryption tunneling between our Kubernetes cluster and Lens cloud. So as we can see it's been installed. If I navigate to my space DevOps care one we're going to be able to see that cluster here. It's currently disconnected now if I launch it it's going to open up and connect directly to our cluster. This may take a moment and of course this isn't that cool yet but once I add a nuke to this and share the cluster directly with him you all will be able to see the power behind Lens spaces and DevOps care being able to actually give your colleagues access being able to give the DevOps care team access to your cluster and so forth. I do want to mention that when you first share access to the space with the colleague it is read only access to that Kubernetes cluster. Now we have also created specific additional permissions that you can leverage where you create a team within your space itself. And in that team you can create an admin team where they actually get admin functionality and so forth all through Lens spaces and DevOps care. So without further ado I'm going to actually add a nuke to the space. A nuke I believe your name is just a nuke, correct? That is correct, yes. Cool, so I'm going to share the team space with them. We've sent them an invite and before I hand over the ball back to them I'm actually going to navigate over to my settings of this space and this is where we actually can see some really cool things. So within members we can invite new members. We already invited a nuke through a different user interface. I can view my invitees. Here we can see that it expires in seven days. And of course I can actually create teams within our Lens space. And what I mean by that is if you have a team of developers that need to access a specific namespace you can actually create a team titled developers adjust the role-based access control on that kube config file and add those members to that team of developers and they will only have access to specific namespaces maybe to review microservices and so forth. From here, Anup, have you gone ahead and accept that you have? Oh, can you accept the invite? Yeah, okay. I was thinking I may want to share it but maybe I can just accept it. Let's accept it first because I'm going to make you an admin on my space which is going to give you full observability into my Kubernetes cluster and so forth. Perfect, I have accepted it. Excellent, cool. We can see that it's been accepted on our end as well. Now I'm going to add a member here. The member has to already be invited to your space as you can imagine and click Anup. And we've actually added him to the space. So what I'm going to do now is navigate back to our cluster. I can go to my home and the neat thing behind Lens spaces is on the top right hand side I can see various different spaces I currently have access to and within each of these spaces there are various different Kubernetes clusters that I can now leverage, work on, troubleshoot, configure and so forth for my team of developers. So if I click team re-event I just want to showcase this real quick. We immediately have the ability to see all of these different Kubernetes clusters. They are currently disconnected but if I click into one it's actually going to populate and load that cluster on Lens through Lens spaces. And then of course if I navigate back to our DevOps care we can see we have a cluster here. So from here I'm going to stop sharing my screen. I'm going to give the ball back to Anup real quick and he's going to be able to show everybody what he is able to see now that he's been able but now that he's accepted the invite to Lens spaces we've shared the cluster to that space and so forth. So I will stop sharing and give you the ball back Anup. All right. Thank you very much. Yes, I did receive the invite and I've accepted it. I would require you to walk us through to what would a developer do next to enable the cluster. Okay. And here. So I can go into my spaces, manage the spaces and I do see DevOps care. I am an admin here and I can click on this. How would I access this from now? Let's let's escape here on the top right-hand side, Anup. Yep. And then hit it one more time. What you want to leverage is that toggle that you see on your top right-hand side where it says Anup to just click that. Yes. And then DevOps care. All right. And there you go. Perfect. Now we have mini cube. That's your cluster. Correct. Yes. And now I'm able to see the nodes that you have and I will see even all the pods. And I can look at the error messages. I can assist you. I can tell you, hey, this is an error message. You need to fix it. You do this to fix it. Yes. Logs. I can exact into it. I can check the logs directly from here. Oh yeah. This is the error message that you're getting. And that's because that pod is currently not running, I believe. Oh yeah. It's dying. It's the MSR pod. Yes. Yes. That is. So one of the questions, Edward, is does DevOps care team need cluster level admin access to the Kubernetes cluster in order to troubleshoot and resolve issues? So that can be done through Lens Spaces. It just depends on really your role-based access control. And what I mean by that is do the DevOps care team really need access to the entire cluster or do they only need access to specific namespaces? So it's really up to you to decide, but generally speaking, we would like the DevOps care team to have admin access on the cluster. Yes. Very cool. Do you need me to show anything or I can stop sharing? One quick thing I would like you to show is if you can go down to that resource map at the bottom, all the way at the bottom, let's see if we're able to showcase this. Nice. So this is an extension that's also built by us that's really helping people get started with Kubernetes, but also anybody leveraging Kubernetes. This is a great resource map that actually showcases everything that currently lives within your Kubernetes cluster, all of the resources and so forth and how they're related to one another. So great extension here will help you troubleshoot. It's going to also teach you how everything's related to one another and so forth. And this is another extension that is built for DevOps care and for Lens and so forth that anyone can leverage. Just one of many, there are over a hundred extensions currently built on top of Lens. And of course majority of those extensions are around security vulnerabilities, scanning for security vulnerabilities. Flux is an extension on top of this as well. And also being able to understand your current costs on your Kubernetes cluster and so forth. So yeah, I think that is everything that I wanted to demonstrate today, Anup. I will hand it over to you. All right, thank you, appreciate that. Thank you so much, Edward. So let's just look at some of the questions that we have. One question from Gyan Rajkumar. Where can we use Keynative? Yeah, so Keynative is something that we are actively exploring. One of the places that we want to leverage serverless solutions is where a cluster might not have enough resources to install all the extensions. So pretty much if a cluster is small and it's just enough to run the applications, we do not want to make it any more worse and cause performance overhead by deploying extensions. And that is where we want to leverage Keynative and generally serverless solutions. And one of the key pieces that we're looking at is in CI CD. If you're familiar with Jenkins X, that's one of the solutions that utilizes Keynative. Another use case would be in security and vulnerability analysis. We do not want to keep something running all the time. We want to surgically run a pod. It would just collect all the metrics. It would run the vulnerability scans, whatever is necessary and produce a report and it gets out of the way. So those are some of the places where we would want to leverage Keynative. Again, we do not have Keynative today at this point in time, but this is coming very soon. And another question from Mick McGrath. Thank you for that. So how do you handle local development iterations? For example, how best to wire up a local file change of a Node.js project to auto reload a running container in a Kubernetes Spark? Fantastic question. So the way we are approaching this is, again, if you go back to one of the things, and we do not have a demo for that yet, is that the Docker Toolchain would be installed in the managed dev cluster. Each developer gets his or her own managed dev cluster. And what this does is this would enable you to treat it as though it is something that is running on your own machine. Like, for example, if you were to bring up a pod, if you were to just keep Kotl or whatever and run a pod and expose it as a service, you will be able to hit local host and the node port and access that particular service. So similarly, when the Docker Toolchain is deployed, you would be able to do this auto, this hot reload of your files directly into the container, and you'll be able to do the tests. So that is something, again, that is something that is being planned and being tested out as we speak, but we have a lot of interest in very similar things, similar workflows to make it easy and seamless development. So that is something that's coming. Please watch out for that. Another question, can you choose the Kubernetes version for the managed dev cluster? Today, you cannot. We run a very lean, minimalistic Kubernetes. It is CNTF, but it is minimalistic. It will be run K0S because that helps you conserve the compute resources and everything, but still, but at the same time, there's a full-fledged Kubernetes distro. So you cannot use your own Kubernetes version at this point in time, but it is something that we would explore in the future. All right, any other questions? Okay, is it possible to customize the metrics that are shown? Yes, absolutely, absolutely. So that is the self-service component that we talked about. There would be avenues where the metrics that are collected, as well as the metrics that are displayed, that you would be able to customize that. We'd be also deploying Prometheus exporters that would be able to collect application-specific metrics. So it could be a particular, it could be a Java application or it could be a MariaDB or something else. So bespoke metrics, that would be definitely something that would be available. Okay, great. Well, if there aren't any other questions, Edward, any closing remarks? The one closing remark that I have, again, thank you so much for everybody for attending. The closing remark is we would have another webinar, the part two, if you will, and that would go much deeper into the technical stack and it'll have much cooler demos than this. We wanted to use this opportunity to introduce DevOpsKit to all of you, but this is something that we are building actively. We have a team behind it that is very excited to address today's DevOps and cloud-native complexity problems. So please watch out for that webinar demo too. Okay, wonderful. Well, thank you all so much for being here today and big thanks to Anup and Edward for speaking today on this topic. Please look for the recording leader today on the Lennox Foundation YouTube page and we hope to see you back at another webinar. Thanks, everybody. Thank you.