 Hello, welcome to the DEVCON 2023. Thank you so much for being here and thank you to the organization for the opportunity. Well, we would like to talk to you today about progressive delivery and argorollout. The idea is to review more or less the basics around progressive delivery and with argorollout. Well, my name is Asier, Asier Cidon for Spanish speakers, Asier Cidon for English speakers is both are okay and well, I'm a senior cloud architect in Iberia and I'm based in Madrid right now and well, I joined Red Hat four years ago, four and a half years ago and I have been working for 12 years more or less in open source related projects. Well, at the beginning I started as an infragai working with different infrastructure and automation solutions, for example OpenStack, Open Nebula, Ansible, Rehab Virtualization for example, but in the last few years I have been spending time working with containers, with Kubernetes, OpenSea for sure and all products or all solutions on top of OpenSea in order to deploy microservice architectures. Well, today with me. Hi, hello everybody, thanks for coming. I'm David Severiano, I'm a DevOps and update architect in Iberia, I'm based in Madrid also, as Asier. I grow as a backend developer mainly with Java application, but now I'm pretty close with Kubernetes, CID, DevOps, I'm so happy to be here and I hope you enjoy this presentation. Well, the agenda for today is more or less simple, we will review some basics around Progressive Delivery and Argo Project and then we will have or David will will give us a demo. It's a real real live demo, ok, for the fingers and we will review the Rehab OpenSea GitOps roadmap for us, it's an spoiler about this Argo CD and then we will have the Q&A, ok. Well, Progressive Delivery. Before starting talking about Progressive Delivery, the main important thing here or the main topic is to talk about deploying new applications releases, ok, that's more or less the idea or the key aspect in this presentation. I would like to review with you some basics around CID, it's only to be sure all of us are in the same page. Well, Continuous Integration, as you may know, is a development practice where developers integrate some changes in code in a shared repository with the idea to include new features or something like that and well, you have an automated process to review this code, unit testing or something like that and the ideas generate an artifact, ok, this artifact in Kubernetes is a image container and the idea is generate this image container, well, after that you have the continuous delivery and continuous deployment, the idea in continuous delivery and deployment is to take this artifact and promote or deploy this artifact in all environments. You have, for example, development, preproduxion, production and the idea is to promote, deploy this artifact in all the environments. Well, the idea in general of these procedures is to deploy or deliver new product releases faster, improve the customer satisfaction, improve the innovation processes and from a point of view, another important thing is to be sure our application complies with different level of quality and performance as well. Well, what is Progressive Delivery? In summary, Progressive Delivery is an evolution of continuous delivery, ok. Básicamente, with Progressive Delivery, you deploy a new version of your application, select as a subset of user or production users with the idea to use this new version, analyze then, you need to analyze the behavior of this new version and if everything is ok, the idea is to increase the traffic or the network. The number of users in this new version using this new version and decrease the traffic in the old version or the current version and you repeat this process until you have all traffic redirected to this new version, that's more or less the idea of Progressive Delivery. How is it possible to implement this strategy? You have both two options, you have Blue Green and Canary, a Blue Green deployment, the idea is to deploy the new version in parallel in offline mode, why in offline mode because you need to test this new version, that's more or less the idea. When you are sure your new version is working fine, the idea is to move all the users from the current version to the new one, ok, in a specific moment. Well, you have different constant pros in this strategy, regarding pros, for example, you are able, you have, it's more or less easy to deploy the new version and to perform rollbacks because you have both applications running in parallel with the same configuration and it is more or less easy and in contrast you have to duplicate the compute resources, for example. Because you need to, you know, you need to move all users at the same time and for this reason you need to have the same configuration on the current version and in the new one. In Canary, it's a little, it's a little different because you need to deploy the new version, for example, select a subset of users in a minimum representation, I mean 5% of the traffic or 10%, the idea is to redirect some traffic to this new version, analyze and observing and analyzing the current behavior of this new application based on, metrics or service level indicators and if everything is ok, the idea is to increase the number of users in the new version and then decrease the number of users in the old or current version. Well, what you have, the idea is to make this change in some steps, for example, 10% and then 20% and then 50% and then 80% and then 100%, that's more or less the idea. Of course, you have cons and pros as well regarding pros, for example, you have zero downtime, that's more or less the theoretical idea and you have a cost effective strategy because you have only the replicas required for all the traffic. In contrast, you have probably some complexity in terms of managing all of these tasks, deploying the application, verifying the new version, managing the traffic, you have some complexity. It takes time because you need to perform some steps and you need to analyze the metrics and probably takes some time and you need power compatibility because you have users in both versions using the same database for example or these kinds of things, sharing some resources. Well, what is Argo? Argo is an open source suite of projects that helps developers in their day to day operations in terms of software, ok? It's a trendy project, I think. Argo was born five years ago but it joined the Cloud Native Computing Foundation in 2020 as an incubating project. As you may know, the Cloud Native Computing Foundation is a foundation, for sure, that supports and helps open source projects to grow, ok? Right now, Argo has the graduated certification. Graduated certification means you have a project considered stable, production ready, you have thousands of contributors and for sure this tool is designed to be used in production. Well, Argo CD probably is the most known project in Argo community. Basically, Argo CD is a tool that supports continuous delivery strategies based on GitOps. In GitOps you have code repository, the idea is to, Argo CD is a controller that manage the configuration, obtain the configuration in these repositories and then use this configuration to configure Kubernetes clusters. Well, that's more or less the idea of Argo CD. Of course you have different features, you are able to read this configuration, you can detect a config drift, you can perform rollbacks, you can implement quick and easy recovery plans, you have different features with Argo CD. Well, but Argo is not only Argo CD. In Argo project you have a lot of projects, you have Argo workflows, for example is continuous integration engine, you have rollout, Argo rollout that we will review in the next slide but it's a Kubernetes deployment, advanced Kubernetes deployment strategies tool. Argo event is to implement hidden driving architectures. Well, regarding Argo rollout is a Kubernetes controller that manage advanced deployment strategies. For example, Ruby and canary, of course, and the most important thing, everything automated, that's the main reason. As mentioned before, progress delivery strategies involves a lot of tasks. I think, for example, you need to deploy the new version, you need to manage the traffic, you need to observe and analyze metrics in order to analyze the code behavior, you have to do a lot of tasks. Well, Argo rollout helps you performing all of these tasks, thanks to many integration, of course, with Kubernetes for sure and with third party solutions, like Prometheus for example, in order to analyze the behavior of the applications, Istio NGNX, I don't know, you are able to integrate with third party solutions in order to perform all of these tasks. Regarding the architecture, Argo rollout is a unique controller, right and go, and well, the idea of this controller is to manage some custom resort definitions, CRDs. You have, in order, regarding the workflow, you have two important objects or CRDs, you have the rollout object, this object includes all information the regular Kubernetes deployment has, and then you have an extra field in order to define the specific strategy. Ok, in order to configure the deployment strategy for sure. And then, when you create a rollout, the Argo rollout controller takes this information from the CRD and creates a set of replica sets and manage the services, the Kubernetes services with this information, ok, we will review this procedure with David. And then, on the other hand, you have the analysis template, ok, where you are able to define the analysis strategy in order to get the different metrics and then be able to be sure this application is working fine in order to take decision for promoting the application, the new version of your application or not, ok. And that's all for my part, David. Ok, demo time, right, but you will have to wait a little bit more, ok, let me introduce a little bit the demo that we are going to execute, we are going to execute a Kubernetes deployment, you already know what is it, as yet has already explained, so I will go on. We have developed a very simple application, we have a frontend application built with React that calls a backend application that is built with Quarkus, that is just an API that will answer with the version of the application. So what we are going to do, we are going to deploy a new backend version, we will start with version 1, we will deploy version 2 and we will see how the version changes. Ok, in order to deploy this demo, what we have done is for the backend instead to use a deployment, a Kubernetes deployment, we are using a rollout kind, ok, also with the API version. In the rollout kind is almost the same as a deployment, the only difference is that we have to add this strategy part, ok, so we have the same as a deployment but adding this strategy part. For this demo we have decided to do a canary deployment, ok, here we also have the analysis template that we will talk about it later. We also have traffic routing, for this demo we are going to use Istio, but our rollout is able to execute a canary deployment without a traffic management, ok, Istio is not necessary, but if we use Istio or another traffic management is the only way to achieve the exact amount of traffic that we want for each rollout, ok. So, for example, for this demo we have defined 3 steps, ok, in the first step we will send 10% of the traffic to the new version for 60 seconds. Sorry, let me do it, let me do it. Spoiler, spoiler, spoiler. Ok, here we are. First step, 10% of traffic. Second step, 50% of traffic for 60 seconds. Third step, 75% of traffic for 60 seconds. And finally we will have 100% of traffic to our new version. Ok, then analysis template, our backend application is sending metrics to Prometheus. What we are going to do with our analysis template is we are going to collect those metrics with a specific query and define a condition. If the condition is success, the rollout will continue. If we have errors, we have bugs in our new version, the condition will be run and our rollout will automatically do the rollback. And our rollout will automatically send 100% of the traffic to the old version, ok. That's very, very important because this allows us to execute more safely deployments. Ok, this is more organized for the demo, we have our frontend that is calling our backend inside service mesh. And we will start with version 1 with 4 pods, ok. Then, when I deploy the new version, our rollout will do two things mainly, ok. First thing, it will create a new replica set, but only with one pod. Why? Because I have said first step, 10% of traffic to the new version. So our rollout make her best to achieve this percent of traffic. But because we have service mesh and the virtual service, our rollout will do the second thing but our rollout will also change the virtual service setting 10% of traffic to the new version, 90% to the old version. We will see that in the demo. So I think more or less it's clear, let's go with the real demo. Let me show you. So first of all, we have already deployed our application. We are using of course Argo CD, eTops model. Here we can see deployment for the frontend. We can see our rollout instead of the deployment for the backend with a replica set that has 4 pods. We have our analysis template here with it and all the destination role, the AV and virtual services. Then this is our frontend application. And we can see that it's answering with version 1. So what I'm going to do is I'm going to set this frontend application to execute one query against the backend each second. So we can see that it's changing. The time is changing and it's one request and the answer is always version 1. Great. We also can see Keali that 100% of traffic is going to version 1. And this is the Argo rollout click. Here we can see that the stable version is version 1. We are in the first revision and we have 4 pods, 4 stable versions. So let's do a change. I'm going to deploy, we have Hem to deploy the application. So I'm going to change my Hem value to deploy version 2. Great. I'm going to make the commit, commit and the push. So just to make it faster I will reference automatically Argo CD and we will see the magic. OK. Argo rollout has seen that there is a new version, has created as I told you a new replica set with only one pod. It has also changed the virtual service and if we see the differences we can see that we had 100% to stable but Argo rollout automatically has changed it to say 90% of traffic to stable, 10% of traffic to canal. I didn't do nothing. It's Argo rollout. OK. If we go to the UI from time to time we will start watching version 2. It should appear as soon. Because we are sending only temperatures. OK. Here it is. We are only sending 10% of traffic to the new version version 2. And also in Keali we, Keali has a little bit of delay. OK. But also in Keali we can see that right now 70% of traffic is going to version 2. And sooner after the 60 seconds Argo rollout will continue with the rollout. And I don't for today. I have to do nothing else. It's the easiest demo I've ever done because Argo rollout will do everything for me. I can sit down here and see how Argo rollout is then in step 2. Argo rollout has created a new replica set. Argo rollout is also changing the virtual service. We can see here 50-50. We can see in the UI that version 2 will appear more frequently here. Also important. Analysis run. OK. There is an analysis run that starts at the beginning. I forgot to tell you. It will be here from all the rollout. It is getting metrics, comparing against the condition. And if everything goes well, it will allow with the rollout. If the metrics are not success, Argo rollout will automatically make the rollout. The rollback. And that's all for me. In another 60 seconds we'll see that Argo rollout will go to step 3. Remember that step 3 is 75% of traffic to the new version and 25% here it is. I'm not doing nothing. It's just demo. So here we have 3 red ligas. Also very important. Argo rollout as you can see is deleting the bots from the old version. Because he knows the amount of traffic that he needs to send to the old version. So with the weight that we have defined. Now we are in step 3. So it's 25% to the old version. He said, OK, only one bot for the old version. So he's doing the scale up and scaled out also automatically. And again changing the virtual service to achieve the exact amount of traffic that we want to each version. Also we can see in Kialli that the traffic is going up to the version 2. We are already in 80% of traffic in version 2. And after another 60 seconds we will see how Argo rollout will automatically create the fourth here this. The fourth bot, the last bot. It will send 100% of traffic to the new version. Argo rollout will also delete all the bots for the old version. Now as you can see we don't have differences in the virtual service because Argo rollout has said. Version 2 as stable. Remember at the beginning we had version 1 as stable. Now the rollout is finished. We have version 2 as stable. Also the analysis run has finished successfully because we were lucky and everything works. And in the virtual service there is no differences because we are sending 100% of traffic to the stable version. Sooner we will see in the Kialli UI that 100% of traffic is going to the version 2. And that's all. Let me a little bit more things that we want to review with you and then we will go to the Q&A. Ok, gtops run map. Version 1.9 of openscip gtops was released a few days ago. And in that version we have Argo rollout as text preview. Ok, so great. We can start playing with it more safely. We can start talking with our clients about it. But take it to account that this is still text preview. But it is there already. And last but not least. Saturday 15.30 we have a workshop about Argo rollouts. It is very similar like the demo that they have done already. But we will deploy cloud native applications using Argo CD, using Helm. We will use gtops model and we will have three exercises. Blue in deployment, canary deployment without service mesh. Remember we can execute canary deployment with Argo rollouts. It is non necessary to have a service mesh or traffic management. And the third exercise we will use Argo rollout, service mesh and everything together. We have all content. But if you want to have to enjoy and play a little bit with Argo rollouts come next Saturday. And that's all. I think we are on time for the questions. So please do not hesitate if you have any questions. I think we have to switch. We have a question online? No? Ok, perfect. I am not sure if I get your question. Ok, so there is application is missing here. So I don't want to know the metrics and hope I send that to Argo rollouts. So we know the application is missing here. With an assistant way. Yes. You have different integrations. You have integration with Prometheus. We did it with a core, a specific core. You have different ways or things. Here we have the Prometheus URL. The query that we want to execute against Prometheus. And the most important thing is you have here the provider. Here in Prometheus. You have different providers. And this is the query. And then you define the success condition. Based on the metrics. Right now we are playing in this example with Prometheus but we have different... There are another provider that is web that you call an API. And based on the answer you decide what to do. To answer the healthy path for example or... Actually, here is a question. Also about analysis in place. I see that they are possible. And about enterprise awareness I guess there is soon... Sorry, I will answer first. I think he is asking about... We can see here a password. This is something that has to be improved. Right now there is not a way to tell Argo Rollout to get this password from this secret, let's say. So it's something that is still... I think on progress. It's the only way. Another question related to multi-cluster. Yes. So in case when... Because Argo perfectly managed with multi-cluster environments. So in case when we also have multi-cluster environments and we should use analysis in place and we have external Prometheus cluster. So how should we solve it? I guess problem also with Secrets. Yeah. First, he's asking about multi-cluster. Argo Rollout right now do not support multi-cluster. So if you want you have to go to each cluster, install Argo Rollout controller and imagine that both controllers, both applications have the same git repository. Argo Rollout will get those changes. But the Rollout will be independently. You can point to a Prometheus outside. We still have the problem of the password. But the Rollout will be independently for a reason could happen that one Rollout finish with the Rollout and the other not. If the metrics are the same, it is not... Right now, this is my guess. I think they will make it work for multi-cluster. They also have set it in the same operator as Argo CD, OPCG TOPS that is multi-cluster. So I guess I know that sooner it will be also multi-cluster, but right now it's not. Remember that the Rollout, the kind is the same as the deployment. So you have your replica for the demo. So Argo Rollout play with this number based on the weight. Ten percent of traffic from four pots is one pot. He makes his best based on the number of replicas that you have defined and based on the weight that you have defined. Fifty-fifty is here. You have four replicas, two-two. This is how it works. Because of that, traffic management. Because when you don't have traffic management, Argo Rollout make his best with the number of replicas. If you have one hundred replicas, very easy. But if you have four and you want to achieve this ten percent of traffic, the only way to really achieve this ten percent of traffic is traffic management with Istio or whatever. There is a lot of configuration properties where you can say more replicas, less replicas, how long the old replicas are there for a rollback. There are many things that we don't have today time to review. But if you want to check Argo Rollout page in Argo project, you will see many, many information. Come on. Thank you very much everybody for coming.