 Hello and welcome to this ArgoCon presentation about progressive delivery. In this presentation, we'll first talk about progressive delivery and why it is useful to make sure that everyone understands the basics. Then we'll see how to implement progressive delivery with two popular tools, Argo Rollouts and Flagr with LinkerD, which is a service mesh that can be used for traffic management. At the end, we'll discuss how these tools differ. My name is Anastasia. I'm an SRE engineer at BT Group. Today, I have Scott, who will represent Flagr and Kostas, who will represent Argo Rollouts. As I said, I'm Anastasia. I work as an SRE engineer at the BT Group, and I support a platform that serves several million users. And today, Scott is here with me and he will talk about Flagr later in the presentation and Scott will talk about Argo later in the presentation as well. Now I'm going to give you a quick walkthrough on progressive delivery and what it can do for us. There are three progressive delivery strategies. Blue-green deployment, canary release, and AB testing. In blue-green deployment, we have two identical environments. The first environment, blue, is a product environment with live traffic. The second one is green with an updated version of the code. Initially, all user traffic is directed to the blue environment, and when updates or changes are made in the green environment and it's ready, we switch traffic from blue to green directing users to the updated version. In canary release, we have also two environments. One with live traffic and the other without. A small percentage of users are directed to the updated version, and we monitor their experience for any issues. If all goes well, we increase the number of users moving to the new version until all are using the new version. And if a problem arises during the process, we roll back or redirect users to the previous version. These strategies help us reduce deployment risk and downtime by minimizing the number of users that can see failure before deciding whether rollback is needed. The AB testing is focused on comparing two or more versions of the product to determine which performs better or has other features. The key distinction is that AB testing is about comparing the performance of different versions, while blue-green deployment is about minimizing the risk and downtime during the deployment process. AB testing can be deployed within the blue-green deployment to compare the performance of different features or changes before making the new version live for all users. By definition, without progressive delivery, all users will be impacted by a failed deployment. Now we're going to discuss service mesh. What does that add to a progressive delivery? A service mesh is an infrastructure layer that adds security, reliability, and observability features at the platform level. So developers do not have to build those features into each service. Those features are automatically deployed with each service. It works by having two main parts, the data plane and the control plane. We call the proxies the data plane because they mediate and measure data communications in your application. The control plane manages all the proxies. Proxies are automatically injected into each service sidecar, a container next to the service container, and all proxies intercept service-to-service communication, allowing them to do specific tasks like encrypting traffic, intelligent load balancing, automatic retries, and more. Unlike most meshes, LinkerD uses microproxy written in Rust, avoiding vulnerabilities that are common in C++-based proxies like Envoy. Rust compiles to native code, making LinkerD ultralight and ultrafast. The microproxy is written specifically for the service mesh use case and doesn't need any configuration. It's an implementation detail and users don't need to become experts about proxies, and that you can focus on the app. Scott and Kostas will explain how the service mesh user traffic during progressive delivery works. Let's see. Well, I mean, you actually explained a lot of that, so I'll give just a little more meat on the bone for this one before I pass it off and then pick back up on it later. So, but first of all, hi, I'll introduce myself as well. Thanks, Anastasia. I'm Scott Rigby. I am a multi-project maintainer within CNCF. I am a community maintainer of Flux, so thank you for welcoming me, Argo people. Argo is an awesome project too, so that's why we're doing it a comparison. I also co-maintain Helm. I've been doing that for about seven years. I am a CNCF ambassador. The program is really awesome. If you haven't even considered applying, and if you're doing community stuff, you should probably apply. I'll be quick about this. And yeah, and I work with them, the CNCF ecosystem, and you can just, and like the general wider open source ecosystem, especially cloud native, so like reach out to me anytime with any questions, and I won't answer them. I'll direct you to someone who will. Just kidding, but I can help or I'll direct you. Anyway, yeah, so I have been getting into Linkerd for a while, so that's why I wanted to start writing a blog post about service meshes, and we all started collaborating on the concepts for this blog post and for this talk that came out of that. So anyway, that's just a little bit about me. I also am involved in GitOps more generally than just being a community maintainer of Flux. I helped to get the GitOps working group and the Open GitOps project really going with a lot of other really brilliant people, some of whom are in this audience. So anyway, moving on now, that's just a little about me and why you might or may not care about what I have to say. But yeah, so basically like the, there's the bit about what Linkerd adds to progressive delivery. I really like what Anastasia said about just explaining the service mesh in general and what value it has and Linkerd in particular as one of the service meshes, a very lightweight choice. You can really use any, but they do come with different pros and cons, so we're just focusing on Linkerd for this time. What it adds to progressive delivery is that the proxy that Anastasia was talking about that controls communications and can do different types of actions including encryption. One of the big reasons why people want a service mesh, like Istio or any Unvoy based service mesh or Linkerd is for MTLS. With Linkerd, it's a much lighter weight solution. It focuses primarily on that use case. What you get is you get encryption not only at the ingress level, really at the edge and encryption and insight there, but you get encryption and insight between every single service. So it's really down to the application level and that's really, really valuable for people who care about security because things can happen, not just at the edge of your cluster, but also between services. So you get all those goodies for blue-green, all the things that you normally get just by installing Linkerd, but with Canary deployments, Linkerd also allows you to have much finer grain traffic, I guess you can say much finer grain traffic progression as you're going through your Canary deployments moving from like say 1%, 2% to like 80 or 100 or whatever you want to be at before you decide let's go full on with the deployment. And Linkerd has metrics as well. It integrates with Prometheus and it integrates with a lot of other things and those metrics can be used for that traffic management for fully automated deployments and rollbacks without any kind of human intervention. So we are going to get into... Well, this section is really flagger versus argoroll. So we're going to talk about... Kostas is going to talk about argorollouts, which many of you probably know, but you might not know all about it, so he's going to talk about some of that just generally. I'm going to then talk about flagger generally and then I'm going to basically take the mic again and then do a little comparison and then we'll see what you all think. Okay, things are easy for me because we are in argocon, so everybody should know everything, yes. So argorollouts, it's one of the four argoprojects. Apart from the argopamily, I know most people are familiar with argocd, but argorollouts is the hot project, of course. I'm working on that as well. One thing I want to make clear is that it's a self-contained project. It works on its own. A lot of people confuse this as argorollouts, you don't. If you had seen my previous presentation, I said we had a hero in the audience that was using argorollouts without argocd. So yes, this is possible. It's a Kubernetes controller. You get out of the box all the nice things that Anastasia talked about, blue, green, canaries, NABs, and also the nice things that Scott talked about, automatic rollbacks with metrics. Another big confusion is that unlike argocd, you have to install it on its cluster. So if you have 10 clusters, there is no option to install it somewhere centrally and manage the clusters. Argosd does that, argorollouts doesn't. So this is something that you should keep in mind. So how it works, there are two options. You get your basic Kubernetes deployment that you already know, and then you extend it with a strategy, either blue, green, or canaries or anything else, and you can either create a brand new resource, which is a rollout, or you can reference an existing deployment from your rollout. So this is how it looks. This is an example where I've taken an existing deployment and I've extended it to have a progressive delivery strategy. In this case, it's a canary, and it starts with 10%, and then it goes to 20%. So if you know how Kubernetes deployment works, then you should know how argorollouts work as well. Now specifically for canaries, which is the most complex scenario and interesting, argorollouts has built-in support for several popular providers, but we also did an effort to implement some standards. The first standard was SMI, which is a service mesh interface, and LinkerD is one of the implementations. But if you are following the news, this is now obsolete, and the new hot stuff is the Gateway API for Kubernetes, and there is an argorollout plugin for that as well. So essentially, if you want to do a canary, you need to check with your traffic provider and see if it supports the Gateway API, and it should. And if the answer is yes, you can use it out of the box with argorollouts. And LinkerD also supports the Gateway API, so there is no problem using both of them there. And I think the most interesting part and maybe the thing that you need to keep from this presentation is that because LinkerD is a service mesh, unlike all the Ingress controllers that you know, as Scott said, but we need to stress it, is that it sits anywhere in your cluster. So this is an example from the official LinkerD documentation where you have a list of applications, and you can see the interconnections. And at every connection, you can say, I want a canary there, even though it's not an Ingress, it's not at the edge, it's not anywhere. So you can have a complex microservice application and say, I want canaries in the internal interconnections between the applications, not just the Gateway, because I think most people think it's a progressive delivery, and they think only at the end user level and at the edge. Some other features that ArgoLouch has, and this is why it's the best solution, obviously, it has its own UI as well. You can use it standalone, or you can use it from ArgoCD, there is an extension there. You get out of the box notifications, and it's using the same engine as ArgoCD. So if you are familiar of how notifications work in ArgoCD, you can use the same mechanism. And you can do out of the box all the nice things that Anastasia talked about with, you know, smoke tests and verifying that your deployment also work. And again, ArgoLouch has support for several metric providers, but you can also use jobs or webhooks. And if you want to do advanced stuff, like header-based routing, where you want to canary only to work if there is a specific header in the request, you can do that as well, or even manage multiple routes. So top of that, Lagir. All right, I made this slide like five minutes before the presentation, so just for you all. Just for you. Gostas is totally right, you know, like Argo Rollouts has a really awesome UI. It has a UI, period. Flagger does not. So that is one gigantic difference between the two. But I'll get into that more in a second. First, I want to just, you know, say, okay, like where we are in the presentation. Basically, we have, we've talked about these individual projects. We haven't really talked about the differences or similarities between them yet. We talked about LinkerD, because that's, you know, the main, I suppose you could say, tool on top of which we're comparing these two. And we talked about, like, how it relates specifically to progressive deployment, which is the real reason why you would use Rollouts or Flagger. But we didn't actually look yet at Flagger and Rollouts. So I'm going to go ahead and do that. By first telling you, though, before we compare them, what is Flagger generally? All right, so I went out just for fun and said the original tool for progressive delivery, just because I wanted to be incendiary here. I don't even know if that's true. It's true. Okay, it's true. But in any case, it doesn't really matter. It is one of the main, the two main tools for progressive delivery within the Kubernetes ecosystem, within the cloud-native ecosystem. And yeah, it's important. Just like Kostip was saying about Rollouts, Flagger supports all the progressive delivery deployment strategies, your Canary, your Blue Green, your AB testing. Rollouts calls the AB testing experiments. I actually personally like that because AB testing is really the, that is the industry standard term, so that's kind of what I use. But I like that Rollouts goes out on a limb and calls it experiments because you can have A, you can have B, you can have C, you can have D, and I kind of like it. But anyway, just know that we're talking about that, the same thing when we're using those terms. And Flagger, one thing that it does very well, although it's totally irrelevant for this talk because we're really talking about linker D, but it works with every single major ingress and service mesh. So in case you feel like experimenting just to compare and like prove out some of the things that we're saying here, you can totally do that with Flagger. And to some degree, you can definitely do it with Rollouts to a large degree. And both Rollouts and Flagger support extended deployment strategies. Specifically, what is it? Canary with session affinity and blue-green with traffic mirroring. Generally, what that means is the header and cookies that Kostas was talking about can be used so that when you are going between blue and green, if you have started a session on blue and you keep going back to it, you're gonna keep hitting blue. You probably all know that, but just in case somebody didn't and then the traffic mirroring means that with blue-green, it means that you are actually still using real user traffic. The actual users aren't hitting your green deployment yet, your green component. But the traffic is actually duplicated and sent there. So it's valuable for certain types of applications and other applications you can't use it for. For example, if you have sensitive database transactions and things like that, staple applications often, you can't do that. But yeah, really, you can do that with both of these. I put this last bullet sound familiar because this should sound familiar because so far, all of this stuff is exactly the same as our Rollouts. Really the same thing. So for all practical purposes, you can do all of these with both of them. Okay, so like, how do I choose? Does it make any difference whatsoever? Well, so the implementation details, they're mostly minor. Costas showed a CRD where you can specify certain characteristics for your progressive for your canary or for the other deployment strategies. Flagger has something similar. It's just different. It has a separate canary custom resource definition, but it doesn't really touch the deployment at all. Let's see. Once one, I'm just going to say slightly palpable, but it's a really palpable difference is what I started talking about and then rewound for a second at the beginning is the UI. So Flagger, again, I'm going to say Flagger is no UI, but that's, I think, because of the difference of where they were coming from. I think according to Flagger maintainers, the best UI for Flagger is the LinkerD UI. It shows everything you need to know about traffic splitting and because of how what I'm going to tell you in a moment about the architectural differences, they do look different when visualized between agrarollouts and Flagger and you have to understand the differences. They both make sense once you know what they do or what the visualization means, but they're a little different. The biggest differences really are the architectural choices, the GitOps ecosystems that each encourage and meaning whether you want to use ArgoCD or whether you want to use Flux and really also which use cases both are good for out-of-the-box which each caters to out-of-the-box. The GitOps ecosystem, this is a really fast slide. It's obviously the Argo rollouts maintainers build Argo rollouts to make it extremely easy to use with ArgoCD. As Costa said, Argo rollouts has its own standard UI, but you can also embed that in the ArgoCD UI. Argo maintainers, please keep me honest, if it's not just an embed tell me, but it looks like an embed to me. But anyway, you can use it within the ArgoCD UI. It works well together. It's known to work well together. It's tested well together. Flagger similarly is part of the Flux project and similarly they're all tested together. Every scenario is automated tested with automation and every release has that kind of testing that goes into it. So what's not obvious is that you can use either with the other. Some of you may or may not have known that you can use Argo rollouts with Flux that's known to work and you can use Flagger with ArgoCD that is also known to work. If you look in the codebase for ArgoCD it even has a test for Flagger in it. That's pretty old, but that's because a number of people wanted it and it's tested to make sure that every release of ArgoCD supports Flagger. You may or may not want to do that but that's up to you. The main point of that last slide is saying that you are not really handcuffed into either solution. You can try them both. Or not. How much time do we have left? One minute, holy shit. So really there's some architectural differences. You can look at this blog post and show the links. I'm going to fly past this because I spoke too much. Basically the main differences that I'm going to point to now are just know that each of these two tools cater to different use cases for starting up. Flagger really boils down to this. Flagger you can get up and running with automation in like five minutes. Most of the use cases you could want right out of the box with the automation. However, on day two it's a little bit harder to reason about because Flagger's architectural choice it makes a shadow deployment. You can look more into that later but whereas Argo Rollouts basically makes two completely separate services and deployments. So it's a little easier to reason about even though it takes a little more work to get started with the automation in the beginning. And that's basically it. Who wins? Your use case. And I give some questions to think about all of which I covered. So take a screenshot of this if you want to and read the blog post which goes into a little bit more detail about the questions you can ask yourself. But basically who gets the crown? Yeah, you tell us. Please give it a shot and let us know. So I'm going to pass this back. So I just wanted to say thank you everyone for supporting our community. Thank you to CNCF for providing interpreters. Please come chat with us at our kiosk in the project pavilion. And tell us how we did. Get in contact. Here's our contact information. Please let us know. If you have any additional questions we'll be around. Thank you.