So, yeah, let's move on to the rest of the presentation. So these are the pros and cons I could think about. That I can think of. It really does like, I think one of the main things about it is that enables automated deployments as much as possible. So you can really choose when you want to have manual gates and when you do that, you know you can use pull request workflow, which is pretty cool.

It is very observable as I said it exposes Prometheus metrics. So you can observe it and create your own dashboards in exactly the same way as you would for anything else that runs Kubernetes. Generally speaking, the pull model that it uses where it pulls config from external source is considered more secure than a push. So with a push you'd have a COI pipeline and that would have access to the Kubernetes cluster. It would have the credentials that can access to push the deployment into the cluster. Whereas this is something that's running either in the cluster or in a separate cluster and it's pulling the config and deploying it into the, the target cluster. And that's generally considered more secure.

I've listed GitOps here as both the pros and the cons. I think it is good. I think it has some, some issues, but like I think it, it's a kind of an all or nothing thing. It's not something you can just do on a whim. One of the big benefits of Argo Cd and GitOps is that you're using Git, which is a very familiar tool. A lot of us and most engineers will have some experience with it. Things like reverting and rolling back and forking are sort of very easy to understand how you do that.

So if you got GitOps with both and you do need to make, you know, a production hotfix and very quickly, you know you can go in and do exactly what I did early, we even just use the Github interface to just change a tag and roll something back. Yeah. So you can use the pull request workflow.

I think I forgot to mention earlier, Argo CD is written in Go, it's also very, very active. It's got a great map and they seem to release new versions every sort of couple of weeks or so. The cons I would say it takes it does take time and effort to set up. I also found with my experience in the past. It kind of takes a little bit of time for everyone to trust it. But forwards has always been an issue. So a lot of what Argo CD is doing is diffing YAML essentially and this doesn't necessarily lend itself well to good performance, particularly if you've got lots and lots of applications that are running. Yeah.

So GitOps I've listed here as well. It's easy to do it badly. I found that if you needed to automate Git operations in a pipeline, that could be quite fiddly. A lot of Git, if you're using the Git CLI. Most of those CLI operations kind of expect to keep repeating to be on the other side. So they didn't necessarily lend themselves well to be automated.

Security considerations there's many, the Webhook is an interesting one because it's not actually there's nothing in the Webhook that is sensitive. The point of the Webhook is just to basically poke Argo CD and say something to change, you need to go and resynchronize. But obviously, if it's publicly available then you know, someone could do a denial of service, you know, to do it repeatedly and then your Argo CD is constantly re-deploying or constantly synchronizing. It's definitely more moving parts than you know, sort of the traditional push it into the cluster from the COI pipeline system. And also more time and effort up front.

Yeah so my conclusion. I really like it, I think should use it, but it's not something you can just sort of bolt on to an existing work play. Ad it's really more about work play than it is about, you know, systems or resources. It's getting people on board is the most important thing. Definitely want to spend some time to think about viability, redundancy, also varies depending on what you're deploying and how important it is, you know, do you need the ability to deploy at all times? Or you know is, can you have like an hour outage every now and again.

I think it's quite important in general just to know why you're doing it and make sure everyone else knows why you're doing it. So what the benefits are. And yeah, take the time to actually integrate end to end. Kick the tires in practice. Yeah. So that's why I think, what do you guys think?

- So it's my first time looking at Argo CD and I think you did a really good job of summarizing the strengths and some maybe potential weaknesses but certainly, I can see why it would be of interest to enterprises using Kubernetes and wanting to scale up. That abstraction of applications makes a lot of sense and helping with GitOps, I think is going to get more and more popular as time goes on.

- My question was, is it, it's just for Kubernetes platforms and that you can't do like virtual machines skill sets or anything like that, or like nomad support or anything?

- No, it's just Kubernetes, say if into it I've gone all in or Kubernetes is like yeah, they were like one of the first and yeah, that's a good question though. It does, it is, it is very Kub specific if you are using Kub you'd probably use it. Yeah.

- Okay.