 I'm Sudhamsh Vachu. I'm from Arcos Labs. I'll give you a brief intro about Arcos Labs, as most of you might not have heard about it. Hi, I'm Remington Breeze, and I'm a software engineer at Acuity. Oh. You might be curious what is don't-let-a-bot-in. I want to get creative so that I could get picked for the lightning talk, so that's the whole reason. Cool. So about Arcos Labs, it's a cybersecurity company. Why I'm sharing about Arcos Labs is, like, why releases are more important to us, what would happen if releases don't work as expected, or if there is downtime. So Arcos Labs protects its customers like PayPal, Microsoft, Adobe, Roadblock, Snap, and a bunch of other customers. It has multiple use cases. It deters bots from creating accounts or hijacking accounts, protects payment fraud on the financial space. Account take-overs pretty much every site that has a login could use our application. New account fraud, like, for example, if PayPal has a promotion for $10, somebody could create used bots and then create accounts and then exploit that marketing. So that's where our product stops users with capture challenges and deters bots. If a manual user is creating multiple accounts, we have different rules and strategies to block those users with complex puzzles and at a particular point, we deny them. So as you see, we have, like, very large customers like Microsoft, PayPal, Adobe, and others. They have very strong observability platforms in their environment. So if our service goes down, they'll detect in no time. So whenever we do a release, we need to be confident that the release will go smoothly and it will not have any regression. So that's where... So we have multiple challenges. I'll share in next slides and why we chose Argo CD for our continuous delivery. With all the amazing talks we had today, if you're not sold on Argo CD, so let me nudge you a bit more. So some of the challenges what we had, multi-day releases, I'm not making it up, as being a SaaS company, we had to make sure release to a region, test it thoroughly, then go to next region, then test it thoroughly. That took multiple days because for a couple of reasons, because we were in ECR and something like Blue Green was not supported out of box. So the end result was, like, 50 different manual steps to be done to make sure that the release goes smoothly and customers are not impacted. Obviously, if you have a multi-day release with, like, six or seven people, you can imagine the toil on the developers, like, dude, release is kind of a dreaded day for everyone who ever was involved in that. So when you have a long release, it has an other side effect. The release velocity would be low because nobody wants to spend multi-day release and then you release once a month or once in three weeks. What would that result to? You will have more rollbacks because a lot of changes are going at once. There is a high probability that something would break. So you spend time in rollback. Then again, you have to do a multi-day release. So that's kind of a snowball and just a downward spiral. And other problem what we had was building always irrespective whether it's a conflict change or whether it is a code change. Kind of goes to, like, different folders and don't build if your code hasn't changed. It's a conflict change you can release without building your image as the code hasn't really changed for you to deploy a new image into your environment. So when we evaluated multiple products that are in the space, what we liked was Argo CD along with the rollouts. So one of the reasons, so multiple reasons as we have heard throughout the day, very fast releases as soon as we make a change in GitHub, then the event is triggered and then you can deploy to all your environments. You increase the velocity. As things are faster, it has a positive effect on the developer's experience. Hey, I made the feature change, so let me release it. And the sooner we release, we are getting a better return on the investment. The time we spend, it's already, it's released to our customers and they are delighted. That makes everybody happy. Products is happy, engineering is happy and developers are happy. And also GitHub's principles. In some of the companies that have worked before, there's a separate change ticket process. You have one level approval, two level approvals based on the complexity of the release. We don't have to do that. GitHub already has protected branches. We already have things for code changes. So if you are doing a code release, why not use the existing process that's already there? And also increasing the release confidence. We can do blue green deployment, test on the inactive stack which is not like taking live traffic and then promote your next version N plus one to take live traffic. This increases release confidence and reduces rollbacks. And with blue green, we don't send any live traffic to it. So we are not affecting any customers. And the north star we want to get to is mirror the traffic from live to the inactive stack so that we get all the application metrics and then our confidence level increases in releases. One other aspect that we looked at Argo CD before choosing that was can it scale as our microservices scale and as the company grows? So that kind of checkbox on the Argo CD it can scale horizontally just as long as the infrastructure in which it's running scales. So it can scale. And also the observability. Yes, I think some of the talks we had like from the Prometheus metrics that are exposed out of box with Argo CD like how do I monitor my, I mean the Argo CD service itself is it deploying or are there any bottlenecks? How do I get visibility if something is not, something is not working as expected? So being part of the release team if something goes wrong, I have to work throughout the night until that gets fixed. But I need a starting point to where the problem is so that's where Argo CD helps by exposing its internal metrics and that you can look at. So before even looking at Argo CD we went through the requirements argument hey, these are the things that we want. You want scalable observability and then blue-green deployment, cannery, notifications, etc. out of the box. So that's the value proposition that's what I saw with Argo CD as Pratik said in the keynote today and yesterday. Argo CD was looked at as a product. It's not somebody put it together hey, this feature looks good, this feature looks good. Okay, let's make it an application out of it. It was thought like a product. There's a single sign-on integration to it. It integrates with Microsoft Active Directory. That's what we use. I was surprised. Really, we use that and then you already have an integration for it so it can't get better than that. Drift management. So GitOps as things change. That's our source of truth. Then our environment would be in sync when we do an auto sync enabled for applications. Metric analysis as part of rollout it integrates with Datadog where we can do the metric analysis and release it. Two more minutes. Okay. So Blue Green, Canada, Out of Box, Slack notifications. So as I said, we had a checklist where a developer would say hey, I'm starting on US Region 1. Do the deployment and then one more Slack message saying hey, we finished on US System 1. That's not good use of time and that would not be accurate because the deployment could happen anytime. So when that is integrated with as part of the Argo CD deployment, then you know that the action happened pretty close to the message that was sent out. Multi-cluster support. One Argo CD can deploy to any number of clusters so you don't have to log into multiple UIs. Command and control for SREs. If a pod is misbehaving, SREs can just restart or delete the pod in production. That's a lot better than getting the credentials from AWS console, updating your credentials file and then connecting to cluster, connecting to the namespace and deleting and somebody could delete it from the wrong namespace. And it's open source. So it's an easy sell to finance team. All right, thank you. So I'm going to speak a little bit about Acuity's partnership with Argos Labs. So as Sudamche mentioned, they have very high requirements for uptime with their product and Argo CD helps provide that but in addition to that comes a higher standard and Acuity helps them achieve that standard. So Argo is a pretty complex product and with that comes a lot of configuration and at Acuity we like to think that we help our customers squeeze all of the value out of Argo. So yeah, some of what we've provided when Argos was having difficulty configuring the Roles extension for example for the Argo CD UI, we helped them to do that. And then on top of that we just have a lot of knowledge here at Acuity about Argo because we are a company of maintainers and experts. So we bring all of that knowledge and help our friends at Argos. And then we also launched last week a platform that makes it easy to configure Argo CD without the box benefits such as security and cost reduction on top of all of the OSS features that you guys know and love. So yeah, thank you guys. Cool, thank you.