 There's a lightning talk, I think I'm prepared to speak for about five to six minutes. I'm trying to speak a general topic about resilience and how to get there, you know, trying to implement and improve resilience as well as the importance of resilience. First of all, I'm a bit of introduction about me and what I do. I'm Uma Mukhera, a maintainer of Litmus Chaos, the Chaos Engineering Project. I'm also head of Chaos Engineering at Harness, the DevOps platform company. Before we get into telcos and why resilience is important in telcos, let me just talk about in general what's happening on the IT in general, right? So the whole reason, you know, this entire conference is happening is, you know, Kubernetes that started, you know, a few years ago. Everybody is trying to ship things faster, right? So speed is of the essence, right? So the entire Kubernetes distributed infrastructure is coming is because, you know, you want to ship things faster, right? And everybody is trying to move to cloud native primarily because of that, right? And one thing that is very, very key while we all move to Kubernetes in a big way, which is already happening is keeping the focus on the quality, right? We want to move to cloud native at the same time, you know, we need to be having enough focus to keep the quality out there. And you know, one thing that can happen is while all your developers are moving your apps onto the cloud native side, are they spending right time on right things, right? So developer productivity should not be lost in doing a lot of debugging because somebody just pushed things a little bit faster into the production, right? So these things need to be very kept in sync. You need to ship things faster. You need to keep things in focus as far as the quality is concerned. At the same time, you need to make sure that your developers are working on the right things, not doing a lot of things on the tech debt or, you know, I ship things faster and I had to go debug. I need to refactor my code. Everything this can become quite tricky if you ignore, right? So you have to make sure that there is enough focus on reliability, right? So that's what's happening on IT as a whole, right? Now we are here talking about telco intro, right? If IT itself is having enough challenges in that part of the reliability space, how about telco infrastructure? You know, telco is always special, right? You know, the infrastructure is kept in focus. It's a telco grade. That's what we generally call, right? So if you talk about the telco infrastructure, there are a lot of fundamental infrastructure pieces that are needed to be working very reliably in a rigid manner. And one of them is, you know, CNFs, right? So container network functions are fundamental pieces of the infrastructure that needs to be reliable. So CNF is critical, and I'm here trying to tell how the CNF test suite is helping achieve that reliability in general, right? So how can you actually get reliability before you get there into the prod is to practice the chaos engineering in the pipelines itself? What is chaos engineering? Chaos engineering is about trying to inject faults in a controlled manner, right? While you are in control and see what you can do about, you know, the weaknesses that are found, right? So you need not actually wait for the faults to occur. You plan the faults and see if there is resilience that is planned is actually, you know, getting tested, right? So if you do this in a loop, that's chaos engineering. It's a well-known concept. But what's new is actually try to do it in the pipelines, right? So the chaos-first principle is all about trying to put chaos engineering before it actually gets into prod, maybe in pre-prod, maybe in your pipelines, DevOps pipelines, so that, you know, you are in control of whatever was already working continues to work under these fault conditions, right? So it's about building, the new innovation is about building the chaos engineering culture in the pipelines itself, right? And you can do this in telco-grade infrastructure as well, right? And how you can do that is there are a couple of a few chaos engineering open-source projects that are hosted at CNCF, Litmus Chaos is one of them. It's at incubating stage. It works, you know, in a very simple way at the same time. It's highly scalable. We have this project, you know, in a high adoption rate. There are thousands of chaos experiments that are run in an open way. And it's highly scalable as well, right? So you can say that it's telco-grade. That really means that, you know, you can really scale chaos engineering experiments using Litmus to a very large level. And we have, I think, you know, in one of the Kubernetes conferences, KubeCon Orange talked about how they're using Litmus to do their pipelines in public and the CNF test suite, which is sponsored by the Cloud Native Foundation, they are using Litmus while verifying the CNF code itself, right? And this is how they are doing it, right? So CNF test suite contains a lot of categories of tests, right? So they build things. They do some security testing. They do some scalability testing, observability testing. And there's also a resilience block, right? So the idea of this is you do some network class functions, latency functions, and then, you know, increase the CPU hogs and memory hogs and see if the application and the test is working continuously properly or not, right? So there is a good reference out there for you, you know, if you want to see how to put resilience tests in pipelines. And the chaos force principle is pretty much easy to do it. This is a simple screenshot of how GitHub actions are being done in CNF test suite. As you can see that you deploy your tests or deploy your functions and then start the tests in parallel. And then if everything is running fine, you know, it may look simple to begin with, but just imagine that there is a lot of code being introduced newly into your relays and your last 10 or 15 pipelines were successful and all of a sudden one thing fails, right? So what this really means that a lot of new code has been being pushed, but, you know, somebody overlooked this particular thing and then you can stop it right there, right? So an example of this is there are about 136 well-initiated tests that are out there in CNF and 10 of them are resilience tests, right? So you can go ahead and take a look at the CNF tests that's out there in public. There are a lot of other references, too, and then try to inject them into your pipelines, right? That's what I'm here to tell you as a way forward. You need not wait for resilience tests to be started when there is trouble, right? Use the chaos-first principle. Use this as an innovation concept in your pipelines. The earlier you start in your telco grade pipelines that is there out there, it's much easier to start, right? And much simpler to start. And then you can keep adding your chaos test one by one with every release. If there is a new feature being added, you can tell your chaos teams, your DevOps teams that, hey, add some more chaos tests to these pipelines and then they get built up over a period of time, right? So Litmus team is, you know, we are ready to help. It's pretty simple to inject chaos tests into the pipeline. And you can join the Litmus channel in the Kubernetes Slack, or there are a lot of reference videos out there, how some of the telcos are using Litmus in their pipelines. There are some good blogs as well to get started. So with that, I would like to say thank you for providing this opportunity and then, you know, go resilient with Litmus chaos. Thank you.