 Okay. So, yeah, as Scott mentioned, this is what we're talking about. I am Priyanka Ravi. I also go by Pinky, and I am a developer experience engineer at Weaver Works. Those are my puppies. Just any chance to get to show them off. And then, okay, so I'm going to basically be treating this as kind of like a little story time session. I'm going to be sharing some user experiences, mine included. And so I've interviewed a few people. Some that are actually speaking here today, which is kind of cool. And I'm going to share those with you as well. So, first up, it is my story. So I actually only recently joined Weaver Works maybe like five months ago. And before that, I was actually working at a large insurance company in the U.S. called State Farm. And at State Farm, I actually was part of a small team that was called the delivery engineering team where we implemented GitOps from scratch. So it all started a long time ago. When I first joined State Farm, the way that code went into production was very tedious and time-consuming. You had to go to a vendor tool and submit a request, and then your manager would go and approve it, and then there would be like a change window. And if you were lucky, it would take days to get into production, but more likely it might take a week or maybe even a couple weeks. So definitely not an ideal solution. I'm sure that story is not alien to some people. I'm sure other people have been in that situation. But eventually, there was another option introduced at the company that we called the automated software change option. I think it was using urban code. And that reduced the time to hours, which was great at the time. But, you know, oh, I'm still wearing my mask. Sorry. That's probably way better, okay? So that made it a lot. That made it a lot, obviously a lot quicker to get to production, but we could do better. And then we had a developer who was actually on my team at the time go to KubeCon. And he came back talking about this thing called getups. And this was like a few years ago. And he was like, wow, this thing sounds so cool. And, you know, we're already using, we were using GitLab at the time. And we might as well just take advantage of that to meet our compliance standards and, you know, make the developer's lives easier. And it's fast. So we ended up forming the small team at the time, just three people. And we, you know, we faced a lot of pushback at first. There were people in the change management space, right? Because in insurance company, there's a lot of auditing. And they also had a bank. So there's a lot of financial stuff as well. And they said, oh, my goodness, you have to meet so many compliance requirements. And we can't actually go this route until you meet all of these requirements. And so we created a lot of tools internally, such as like CLIs to get things into the config repo. And then we also used Terraform to create those config repos and keep them locked down so managers could approve in there. And that whole process was a lot of work to meet those requirements. But eventually we did. Then we heard from managers, well, we don't actually want to have to log into GitLab because we've never had to do that before to look at code. And now you're telling us we have to go approve merge requests. And so that was the next step. And but the thing that really kept us going is that on the other hand, we heard from developers, if you can make this work, then you'd be our heroes because this would simplify our lives. We don't have to go to a separate tool to get approval and all that stuff, right? It's all just in what they're used to. So that kept us going. And eventually we did get it set up. Actually, the first platform we were trying to get it set up for was AWS, not Kubernetes actually. And so we set up all these tools and everything. And then Kubernetes was the next piece that we tackled. It was very exciting because we actually, that was my first introduction to Flux. But the challenge there was a new one where at State Farm, Kubernetes had already been in production for a couple of years. There was a team that was the dedicated Kubernetes platform team, and they had been doing this for a while, right? So we're trying to come in and be like, oh, let's change entirely how you're doing what you're doing. We're going to change the way that namespaces get created. We're going to change the way that users get onboarded. I mean, that's not going to be an easy conversation, right? They're not going to happily be like, yes, please change our process. So we had to do a lot of work with them. We did a lot of proof of concepts to show them that it wasn't so bad and that this is a very simple thing to do. And at the same time, there was already a UI in place to get new people onboarded. That was the way that they had been doing it, and then it would call off to the API and do all these other things, right? So we just used the same UI to then create, like it was a pipeline to create the YAMLs for the Flux multi-tenancy repo to create those new namespaces. So that Flux could then pick it up and just create those namespaces. And that at least made them feel a lot better because then the users that have already been using that whole way of getting onboarded onto Kubernetes at the company didn't feel any difference, right? They don't care how it gets created as long as it's the same experience and it does get created. So that also helped bridge that gap with them. And eventually, they actually were really excited about it and they took ownership of it too. So that was like a great accomplishment for us as well. And I want to add too that, well, I don't know what's happening at the bottom, but I want to add too that we would never have been able to do it as quickly as we did. We got it up and running within, we got get-ups going within a year. It wouldn't have happened if we didn't have leadership buy-in. I think leadership buy-in is a huge thing. It's a great asset to have if you can get it because if the leaderships are telling, if the leaders are telling teams that, hey, this is the direction we're going in, things are so much smoother. Otherwise, it's a lot harder to get different teams to buy into this aspect as well, to make a change because they're like, it's already working. Why would I want to even do that? So that was my experience. The next one I want to talk about is actually kind of funny because if you're at my talk, you're actually missing her talk. And so this is actually App Flyers, their experience. And so if you, like, since you're here, I really encourage y'all to go check out I Let's Talk online later. If you get a chance. So basically with App Flyer, their company just exploded. They got really big, really fast, and their infrastructure grew exponentially. And, you know, they really had to adapt. So because it grew so fast, their developer experience started to deteriorate. They started to have a lot of pain points, such as fragmented work, the developers needed to go through multiple resources and services for a single commit. They no longer were independent, and they had to actually get help from the platform group to do any actions. So basically what they did is they created a cross-platform team because they had seven platform teams in their platform group. And they had representatives from each of them, and they actually used Flux in the base, and then they added a bunch of additional custom tooling on top as well. Like I said, I really recommend you check out her talk to find out more about how they actually did it. But their initial reaction to GetOps was not the same experience that I had. Theirs was not fireworks. It was actually, the developers were not excited about it at all. They were actually very apprehensive of it because they didn't like the fact that their environment was changing and the way that things had to go were different suddenly. So they actually solved that by using different representatives from each of the R&D teams and basically created this champions group. And then they were able to then go back and take that back to their teams as well. As well as they actually had leadership buy-in as well. So their CTO actually did a talk and everything about GetOps being the way to go. So that also helped make people realize like, yes, this is the direction we should go, and they felt better about it if they heard their leader saying it, right? And for them, building out their GetOps solution actually brought on amazing results. It reduced all their developer pain points and increased the number of developments per minute for them as well. So that's very exciting. So another one I want to talk about is, so this user is someone I interviewed that actually works for a SaaS company. So interestingly, when I was talking to them, I got their company perspective as well, but I also got to hear some of the stories that they've seen other people have as well. So for them, they have a bunch of microservices and they were actually using Azure. So they didn't even have GetOps in place at all and not Kubernetes. So they created a team, a dedicated team to start Kubernetes, but they had the opportunity to actually create GetOps alongside Kubernetes. And their end goal is to actually have everyone on Kubernetes using GetOps as well. So they actually said that they like Flux because it's a set and forget type thing. You just kind of set up Flux, point it to something, and then you can kind of forget about it. But one thing they said is that they've seen some really crazy pipelines and setups for deployment that are ridiculous. I'm sure you all have heard of some similar ones like this, but just really over engineered. Basically, this one was, so they were using Terraform to set up their infrastructure, which is not uncommon, right? Where it gets really crazy is that they were using Terraform basically to what it was doing, it was creating, sorry, I have to read this, because it's not something I could even memorize because I can't wrap my brain around it. So basically, the process to create it was literally pushing the code to a dev branch that then gets built and then there's a new Helm chart with that version that gets created and then that just stops. And then they merged that into some other branch, which then did the entire process again, except this time it actually deploys the Helm chart. It was insane. It's a crazy process. I'd never heard of anything like that, but I've heard of some other situations similar. So getting something like that into production, literally even a simple website UI took them an hour. After they told me about that, their next words were literally if they had been using GitOps. Everything would have been a lot easier for everyone involved in that situation, right? And they had also helped another one of their customers who was using Kubernetes, but they were super new to it and they were doing manual deployment. So they nudged them gently towards GitOps. And one thing that I thought was really neat is that these people had not actually been using Kubernetes very long. They were very new to Kubernetes, but they pointed out that even they were able to wrap their heads around the concept of GitOps really easily, which was pretty exciting to hear because it makes me happy that it's not so convoluted that people can just understand it even if they have a basic understanding of Kubernetes. So anyone can really do it. Yeah. So last thing I want to end on here for this user story is they actually had a really good point they brought up. I think what they said is they keep hearing this misconception, and I've heard it too, is basically GitOps is just the deployment part of it. It's not the whole CI process. So all those tests and scans and everything, sometimes people think that they get a little confused of like what does Flux do or what does like any of these GitOps tools do. And so by that point, by the time Flux comes along, the test scans, all of that should already be done. So that part is just the continuous delivery part. And I just wanted to emphasize that. So now I want to see if there is anybody in the audience that has a story they want to share because we have some time. I think I've got a story to share. Okay, cool. No, this was totally not staged at all. Just wearing a mic. Just by chance I have a mic already. So yeah, I figured, excuse me, I did share a little bit of my story. I know I just gave a talk a little bit earlier. And so some of them I've already heard the story before, but so sorry to you all. But previously I was working at Virginia Tech. And at Virginia Tech, we were building a platform just like this. Many of the stories that you have just shared with us. And GitOps was a good separation point between the platform teams and the application developers. And there's kind of two things I want to bring up that GitOps helps solve for us. When we first got started, we recognized that there was a missing piece of how do we provide kind of a web interface kind of thing. Because mostly the dashboards out there, if anybody's ever run a Kubernetes dashboard, good luck trying to present that to the lay person. And so we built our own dashboard that took a lot of the different components and kind of wanted to present it in a read-only manner as GitOps would support. But one of the things that we did with that dashboard was that we would highlight specific problems or things that were going on. So then it would kind of help nudge the application developers along. And one of the really neat things that happened out of that was since all the teams are using Git to version control their deployments, we started watching new teams that were spinning up. And we would watch them to see what was their journey of learning. And so we would see a lot of times that the very first commit is, OK, I deploy a pod. And OK, that's cool. They see a pod spin up. But they can't access the pod. They can't open up a web browser to it. And as part of our dashboard, we had a little bit of, OK, hey, you've got a domain here, but it's not connected to any pods. And so we kind of give them the next step. And we would see the next commit is, OK, here's a service. Here's an ingress. And we could kind of see that commit history as they're learning and going through that kind of learning journey to help walk them through that process. So in many ways as a platform engineer, using GitOps helped us kind of see where the common stumbling blocks for our developers were. And how can we help them out? Another aspect that we were pretty interested into is going to application developer teams and simply saying, hey, here's a platform. Congratulations. Now you have to learn how to write all this Kubernetes stuff. Good luck. And so we had a lot of developers come back and like, OK, I'm writing a service. What the heck is a selector? And what are these labels? And in all this stuff, and it was just so complicated. So we did a lot of experimenting internally of, can we use the compose spec? A lot of the teams are already using Docker compose for development. Can we use that same specification, add some extension fields and say, OK, for a port, here's an x-host field. And we can convert that and use something that they're already familiar with and convert that into the manifest that could be deployed on the cluster. And we had some pretty good success with that. I'd love to still do some experimenting with that. But I think there's some work as a community that we can do to kind of raise that abstraction level for the developer teams. But I think GitOps and this kind of this boundary layer between the platform teams and the development teams, it's right for a lot of really cool work and development there as well. Did we say your name? Oh, yeah. I didn't even say my name. Pinky's just like, you didn't even introduce yourself. So my name is Michael Irwin. I'm currently an engineering manager at Docker. But a lot of my experiences that I've been sharing today were about my time at Virginia Tech previously. So one thing that I really like about Michael's story, too, that's different than mine, is that they got to stand up Kubernetes and GitOps at the same time. So it was like the same team that managed both. And so the whole thing is like, if you haven't already stood up Kubernetes and you're here to get started with both, it's a great opportunity to get started with both. You don't have to retroactively fit GitOps into your existing Kubernetes structure, which is cool. If you have that opportunity, if you don't, I mean, it still works. I'm here as proof that that still is possible. But yeah. So that's kind of what we wanted to say, too, is you really can do this. We've both implemented it ourselves. And no matter how crazy your situation seems, there's a lot of really crazy situations out there. I think we've both heard stories that are insane in our time working with Flux. But it's totally doable. You can definitely make it work. And as I mentioned before, if you do get leadership buy in, it makes it so much easier. And then another thing that I forgot to mention with my experience is doing a lot of talks to actually help developers get started with it. I think that really helps. I did a lot of talks when I was at State Farm to actually promote it and then make people feel a little more comfortable with it. We did workshops. We did a lot of that stuff. So that really helps as well. Yeah. And then we have a Flux booth here. Nice shirt. Yeah. So if you do want this shirt, we have a bitly up there that you can go to and you can come meet us at the booth. And then we have these shirts as well. So we just wanted to see if there were any questions at this time. Not pre-planted questions. Yeah, this is real.