 Thank you. It was done right on time and this is the last session They say keep the best for the last Starts with the keynote and ends with another keynote. So hopefully I do a good job Are you all ready up for the last 20 minutes, right? Just to introduce Myself. I'm Uma Mukara I'm the co-founder and CEO of a company called my data. I work out of Bangalore. We are headquartered in Silicon Valley We are a cloud native data management company predominantly working on Stateful applications on Kubernetes and we use GitLab heavily when I say we there are two parts to it One is as a company We do GitLab internally for CI and CD as well and then we have a huge Open-source community around open EBS and then we see a lot of GitLab coming in there, right? So today What I'm going to talk about is how we are using GitLab as well as how our communities is in GitLab What are the common use cases around it, right? So Let's quickly talk for a minute about what this two fantastic open-source projects that are part of CNCF Kubernetes ecosystem are The first one is open EBS. It's really open-source equivalent of Elastic block storage It's a container attached storage for stable applications such as GitLab on Kubernetes, right? you must have heard about NAS and Das But CAS is something that we defined as a new category in storage. It's container attached storage You know Kubernetes is all about dealing with You know portability of applications from anywhere to anywhere, right? So that's why stateless applications are so good and then when it comes to data The stateful applications that is a stickiness, right? And then container attached storage is about putting that storage software into a container and then you know Treat it like a container so that there is no portability problem, right? It's a cloud native sandbox project on CNCF The other one that we are sponsoring which is still with us and we are hoping that it will go to Same path as sandbox is litmus It's a Kubernetes native chaos engineering project for both developers as well as SRE is managing the operations So what are we going to talk about? I think I just touched upon a little bit, right? So how do we use? GitLab at my data as COO. I manage operations in our company, you know, we're a startup Operations really means the software operations as well, right? So how are we using? GitLab, right? I mean like we did try Jenkins to begin with But this concept of CI and CD together was really The one thing that made me decide let's go with the GitLab, right? So what we did is We actually liked how CNCF is doing the CI platform I don't know how many of you are aware of CNCF.ci It's a CI platform for all the graduated projects Within the CNCF ecosystem. So we took some kind of an inspiration from that and then Created a front end to our entire CI platform at its open What I meant by open CI platform is the scripts and the way we built all our pipelines is also open source, right and As you can see that it's it's powered by GitLab and All it's about also transparency, right? So, you know your your users should really believe in how you're testing your code, right and As you can see, you know, like there are each commit goes through various tests before it actually gets merged into the mainstream and There is something different about the last stage. It's about chaos testing, right and I think Someone Roger from Siemens. That was a fantastic talk towards the end. He touched upon reliability, right? Kubernetes is really Coming in because the way you do DevOps is much easier much more effective But it is about reliability. So how do you actually make sure that this open EBS project or Whatever you deploy in a Kubernetes cluster is really Reliable, right? So unless you do chaos testing and make sure that all failure scenarios are covered You cannot say that it's it's reliable. So we'll talk a little bit more about, you know, how anyone can do chaos testing Using Litmus and GitLab in a bit, but that's how we're using at my data and Then that's that's one use case. The other one is GitLab itself, you know, we are running on-prem, right? And we're not using the GitLab cloud One reason is there are many users who are trying to deploy GitLab on Kubernetes their own cloud account or their own, for example on OpenShift or other Private cloud platforms We see a lot of them are using open EBS as the shared storage for various applications that are That are there. These are all stateful applications. So There needs to be a good Storage on your private cloud for your GitLab instances. So we see a lot of that GitLab being used for it. So what we thought was why don't we actually deploy that for ourselves so that we doubt food? Open EBS for GitLab, right? So this is how we're using GitLab. So you what you see open EBS.ci. It's really coming from It's a CI platform for open EBS running on open EBS itself, right? So just imagine you get in a wrong check-in and then your CI platform itself will go down, right? So that's that's the bet that we are taking To make sure that the code is maintained at a good quality level. Well, that's that's how we are using my team And then how is our community open EBS community using GitLab, right? We see as I said a lot of them are using Open EBS and GitLab for on-prem as a combination on Kubernetes. That's good And the most interesting thing is they're solving a good challenge. That is typically phase by Developers and SREs together in the cloud native ecosystem world. It's also called data DevOps But also it's you know, some people term it as cloud native CI-CD for stateful applications Right. So let me talk. This is probably the topic that attends more interest in general So what are the main challenges in cloud native CI-CD? Of course, GitLab itself has converted the application into a Helm chart that runs very well on Kubernetes so you can just use it deploy it in few minutes All you need to do is just this change the storage class to open EBS and then everything is done, right? So that's great, but there are a couple of other challenges that you typically face. The first one is, you know It's about data, right? Your CI pipeline has to run on the latest data that's closer to the production So how do you make sure that the data is closer to your pre-production, right? The second one is, you know, it's about agility developer agility So I merge my code Well, CI actually tests and then, you know It all tested the pipeline ran within 30 minutes or one hour and then it failed I merge caused a problem. Now I want to debug, right? So that's how do I get the exact state of data at the instance of failure so that you know, I can just go and you know debug and then fix that problem. So these two are something that The common issues that we see as a GitLab community using us both Open EBS and GitLab So let's actually Talk a little bit more about the two use cases, right? So this is what you typically see in DevOps You have a CI cluster and then this is also generally called as multi-cloud CI because, you know, your production and pre-prod are in some reliable platforms or In more secure platforms like, you know, your own data center But your CI is more closer to your developers and then, you know, it's somewhere else, right? So this is your CI cluster That is it's called seed data, right? So the data on which your application starts testing, right? And then you run your pipelines on your seed data So the challenge here is how do you get your seed data from, you know, from closer to wherever your users are To place where your developers are testing your code through the pipelines, right? So I was actually talking to seed yesterday during dinner and then he really Gave this name. I was telling, you know The data gets massaged from pre-prod or prod to pre-prod and then, you know, gets in he said no There is a name for it. It's called pseudo naming, right? The idea of pseudo naming is you take your production data Of course, you know, like your customers are not going to allow use it, right? So you replace that all the personal data with some, you know, dummy data So that's a good practice that's followed in a standard way by all DevOps teams And then they know how to get the pseudo naming, but on Kubernetes the challenge is how do you really get this data From pre-prod to your GitLab CI cluster, right? So that's that's one thing not only get once you need to keep Getting it again and again and then you don't want to be spending any time in getting it You want to automate it, right? So get that now get that next week or probably get it daily if your Data is changing so fast, you don't want to be getting it faster So how you do this is OpenEBS has a feature called data migration as a service Where you take the snapshot of the data and then move it on to your CI cluster and then, you know Your pipin is drawn really on that the data The second problem is, you know, I as a developer I merge my data code and then it really failed You know, not very common, but it does fail, right? So that's why we do CI So when I see a failure in the pipeline, I want to get access to the data So what you do is if you're using OpenEBS as storage for your stateful applications in pipeline You can just call the snapshot API and it's very easy to call this API from your GitLab CI ML And then you snap it you clone it and then give it to the developer So, you know, for example, we use this for our own SaaS platform and then there were instances where You think it's a big problem, but you know, still it's a null check somewhere. It's failed So you you go ahead and then fix it immediately and then the code gets merged An hour later all all good, right? so that would have saved few days of Setting up manualing and then this is just a map of how our we have another product called OpenEBS director That's a visualization tool for You know, what's happening with your OpenEBS or litmus? So let's say that you got your seed data that is received from your preprot, right? And then you whenever you get it you again take a snap of it so that for every Pipeline you can clone the data, right? So as you can see the vertical lines these are for each pipeline that you run You are really running it out of a snapped data, right? So for a successful pipeline you just clone the snapshot everything went fine done, right? What about for a failed pipeline, right? So a failed pipeline whenever it fails as you can see here You are a snapshotting again and then you are cloning it and this is the instance that you give to the developer Where there is latest data available that caused it is his or her code to fail the pipeline. So then you get That's the debug instance, right? So this is called auto Data DevOps, right? So everything is automated right from preproduction all the way to the developer, right? Using snapshot clone de-mass and then GitLab CI So that's the first topic and then we also have Chaos engineering being used and then this is more related to the reliability that everyone is talking about Before we go to how GitLab and Litmus can help you achieve more Reliability for your stateful applications. Let's talk a little bit about chaos engineering itself How many of you practice or heard chaos engineering? Great for some reason I see a chaos engineering is more popular in London and no reason why but a Lot of conferences happen here. So that's that's great. So Reliability is too important. What happens if you don't have that reliability? It's not just not cost little money a lot of money and If you are very popular it causes the damage to your reputation as well, right? So the service outage is a problem. I mean no offense to GitHub here, I'm not saying Intentionally, but you know, oh This is one of GitHub is the most Widely used, you know developer platform and then it also went down, right? And Similarly, there are other examples like Slack AWS. So why do this go down, right? So is it that they don't test it well or they don't know how to do it? They have the best SR is in the world right looking off to their website So Why do they go down, right? That's because it's almost impossible to predict What is the kind of a test scenario that your production environment is going to go through? You can never predict because all the time it's keep changing and then you don't have control on some of the things, right? so What do you do? In production, you know, like CI is one stuff in production. You go break things on purpose You observe and fix them and then you keep continuing them, right? So failure testing versus chaos testing failure testing really ends at CI the pipelines then you do the CD, right? So chaos testing extends the failure testing into the production. So you never stop Injecting false. You never stop testing in production, right? And then there is something called chaos engineering loop. This images have taken from slides presented by Mark McBride, his known authority on chaos engineering, his CEO of Turbine Labs, so the way he explains is really important and very nice So what he says is, you know, typically in usual engineering loop You got a good stable system things are running fine and then something happens It's called incident and then your entire incident management kicks in and you start doing the firefighting, right? So all the way from the SRE to the developers to your CEO everybody is on the call Right, and then you resolve it. Then what happens? You start observing again. That's what we all know So in chaos engineering loop, you don't wait for the incident to happen. You start actually you do a planned Injection of failure, right? And then you don't firefight You actually analyze the system and you still tune the system. You don't fix because you know you're basically tuning a little bit and Start with a small injection of false fault injections and go bigger and bigger as you tune them So this is more, you know organized chaos type of a thing And then this is what is chaos engineering loop and this is how you know the large enterprises or even small with the critical applications that are in production are expected to follow and then I had Also opportunity to speak at the other GitLab and the conference in Brooklyn So I really observed something there, right? It really struck me So it's not just that I gave in the conferences. I actually get a lot of knowledge, right? So this is Dan Kohn You know his executive director of CNCF. He was basically talking about why CI is important, right? This was in the keynote of GitLab committee itself so You know fundamentally what we are saying is as you move to the microservices world You can see that, you know, this is Linux Kubernetes Node.js and then you know the lot of third-party tools and finally you have your own piece of code Your own piece of code itself is not small here in this example. It's 40,000 lines of code, right? But compared to your entire stack that can cause your software to fail Your code itself is 1% Right, so and then Linux is the least dynamic stack Just imagine how fast Kubernetes is coming and with microservices world Everybody is releasing almost like every month or sometimes faster than one So your code is changing so dynamically and then, you know, you put CACD in place Oh, okay, my CA pass. So let me just put it into the CD. GitLab does a great job of actually, you know, pushing things into production in an automated way So you think that, you know, everything is good But you're actually depending on 99% of somebody else's code to make sure that your service is reliable, right? So So how do you achieve reliability or resilience is the answer is chaos engineering, right? So that's chaos engineering requirement But what is cloud native chaos engineering, right? So it's really about Introducing random chaos into production It's about, you know, you have to have a good CI But also you have to have the systems to introduce Analyze and tune your systems by introducing random chaos. So how do we do that? Right, so cloud native, we're all moving to cloud native, right? That is separate track running somewhere else I was thinking I was going to speak there, but I'm happy that it's actually more related to DevOps, right? For development, Kubernetes has created a lot of standard APIs like pod, PVC, service, deployment, stateful set And also they've introduced custom resource definitions or CRDs, right? How about for chaos testing, right? So Thanks to the feature of custom resource definitions We have a possibility to create CRDs for chaos, right? So these are some of the three CRDs that we have Defined I'm going to explain this a little later. Chaos engine CRD is the one that links your application to the chaos Chaos experiments here is really the experiment, right? And then chaos result is okay You ran chaos. It's also very important to observe what has just Happened Right. I keep introducing this chaos all the time in random fashion probably a couple of times in a week Everything went fine, but now it failed, right? And it's important to analyze, you know, what has changed out of my 1% code Nothing has changed maybe a small fix. I'm pretty sure that it didn't break But there is another something else has changed in the 99% of the code that I don't own So it's important to actually analyze what has changed. So CR of chaos result that will help in, you know, putting some code around Observation, right? And let's see in cloud native chaos engineering How easy it is to deal with your chaos as a developer, right? As a developer First thing I do is create a pod and you know it very well It's all about creating a simple ML file using, you know, the standard Kubernetes way and to create other Objects Kubernetes objects you do the same thing, you know I want to create a persistent volume. It's very simple and I want to inject chaos now, right? So again, it's the same method you create another Kind called chaos engine chaos experiments and then there you go. It's all done, right? So that's why we call it is it's Kubernetes native way of Injecting chaos and observing right and it's like kind of built-in into your Used procedure of how as a Kubernetes developer or an ops person how you're dealing with your Code or operations you can do the same thing The chaos also in the same way Well that Brings us to okay. This is good concept. Is there something available that does that already, right? Yeah, that's litmus, right? So litmus chaos that I was a website the main pitch for that is cloud native chaos engineering for Kubernetes developers and sre's and We have come up with another fantastic concept called chaos hub. This is where I actually personally Like potential, right? So what happens here is as developers, you know, we are all Dealing with CI admins pipeline admins and then you write your test cases, right? And then there is a failure testing. There's a functionality testing. So you need to actually Do the failure testing of the 99% of the other code, right? So how do I get the test case? Well, you can get it from chaos hub, right? And then you write your application chaos test and push it back to chaos hub It's just like operator hub table for thing, right? So this is the place where your chaos test cases or experiments or you know shared Among ourselves most of the code is open, right the applications. So you're using many of The services which are an open right and then you use that So how are we using chaos engineering and GitLab? There are two ways how to do chaos engineering within the pipelines and the other one is how do you verify? you know my GitLab on-premise itself is stable or not, right and for the first one chaos engineering pipelines is There must be some experiments already they use them and then run your test and We are working with you know each communities such as GitLab community and ask them to Contribute chaos experience back to the hub. So for example, you know, there are no available Experiments we have something for generic chaos. It is recently launched a few weeks ago So we have a chaos experiments for open EBS application The hope is you know, we start working with all communities for example GitLab could be the next one Obviously pitching them. There is a use case for you and your users to have chaos, right? So How to use litmus in GitLab? It's pretty easy. You have the charts Install it on your pipeline that installs an operator on libraries then pull the charts and then that gets installed the CRDs and CRs and then you inject chaos using the ML files and then chaos is done result is ready it's as simple as that right and We went ahead and did one more thing to make it easier for GitLab users So we we took this charts and then put them into the GitLab remote templates So if you are writing a CIML file, it's just like you know, it's it's a matter of Taking that template and then changing the labels of you know, what's my application label and What are the parameters what's IP address whatever the service name and done, you know, it's it's it's as simple as that and For example, you know, you do the CIML and then what happens is you can inject chaos testing. It's it's pretty straightforward Well, that brings us to almost the end of it and we're all about open source, right? Please Try them criticize them get benefited. Similarly if you're a GitLab user, of course, we are a lot Contribute more templates to the litmus and then hopefully in your application, you're going to create more chats Chaos charts and contribute back to the chaos hub. So please do all of I mean make use of the three open source project GitLab, OpenEBS and Litmus, thank you that brings us to the 20 minutes. Hopefully I am now ready to take some questions If you put me. Thank you. Thank you very much