Argo CD’s Rise and the Future of AI-Driven Deployments

Hello, everybody. We're back in Amsterdam at the KubeCon + CloudNativeCon Europe Conference, and I'm talking to my friend Hong Wang here from Akuiti, and we're going to have a little chat about, well, Argo CD. There's been a lot of momentum building around Argo CD now for several years, and it seems like it's finally coming to a tipping point in terms of adoption and...

Are people thinking differently about CI and CD these days? What are you seeing exactly? Definitely.

So the Argo CD has been on this long run, and personally, I have been the creator and have been working on Argo CD for about 10 years. And nowadays, I think last year, the CNCF published a survey talking about 67% of the people already using the Argo CD in production. That's technically a majority.

So I think the Argo CD is already the clear winner for the GitOps in the Kubernetes space. So what we are seeing the trend here is, originally people are looking for, okay, I have a CI/CD system, like GitHub Action, GitHub CI to do everything. But Argo CD proved out is actually you need something specialized for the CD.

That's why people using, okay, GitLab or GitHub together with Argo CD. But we do think we have additional innovation on top. That's why we introduced this new concept called continuous promotion.

It's doing the multi-environment promotion and making every environment to be the first-class citizen. So we actually introduced the Kargo about two years ago. Right.

So I think I saw at the show there's a new version of Kargo floating around. What's in there? Yeah.

We have the open source version for two years, but we are keep adding new functionality on top. So last December, we announced our Kargo version actually supporting Terraform, VM, and serverless promotion now. And today, yesterday, we announced that we actually making the Kargo be able to run custom steps.

So the main usage for that is actually right now security validation or maybe any customer scripts you want to run during the promotion. So we making like catch all use cases means that you can be customize your experience and do all the things you need during the promotion. What was different about CI/CD and Kubernetes versus what we were doing in monolithic applications?

Because for so long we tried to couple CI and CD together. Mm. But it feels like with Kubernetes, we shifted more to this GitOps mindset.

But what drives that at the end of the day? It's actually an excellent question. So I have a lot of saying about it.

So the traditional Jenkins or GitHub Action jobs, it's jobs. Means it's run to finish. It's kind of like, oh, it's successful or failed.

That's it. Basically, it doesn't continuous getting the status of your application. It's kind of like, oh, I run, successful, done.

So things could be changing even after the deployment was successful. So what it changed for the Argo CD and the Kargo is, we do the promotion during the deployment, but since then it stops there. We actually continuously monitoring your infrastructure, understanding what's going on, and that's where the people needs.

It's kind of like, you don't need a job run to finish. You want to actually constantly understand what's going on about your application. Are they healthy?

Are they out of sync? Or someone actually change something behind the screen? So you want to know about it.

So that's give you the massive visibility. Have we also maybe started to see a little separation of concerns? Because maybe the CI part of that equation is really in the developer realm, and the CD part is more in the software engineering, DevOps, platform engineering team's concern.

And is that also driving this? Yeah, I think exactly to the point. Totally agree.

So it's kind of like the CI is mostly for the, I would say, the development. Basically, okay, you got a new change, you want to build your binary, building a Docker image, running some testing. But for the CD side is more, I think, in the realm of the platform team, DevOps, SRE.

Because what is the ultimate goal for the CD is actually we want to release something to the production. It's a very high value, high risk, in higher level activity. Means if something's broken or something released causing the outage, we are talking about maybe millions of dollars.

I work at the Intuit for four years thinking about what's the time now? Okay, in another month, we have the tax due date, middle of April. So every 10 minutes is about $10 million for Intuit.

So that's scary. That's why people are actually looking for a very customized experience for their deployment experience. They want to minimize the risk.

They want to have more visibility. They have better control of it. That's also all the reasons why we build Kargo, also solving that very practical usage and meets that needs.

One of the things, too, about Argo CD that I've heard is that people actually like the graphical experience for managing CD, and they don't necessarily want to do everything using programming tools. Yeah. Are people flipping in and out of graphical, the programming tools, depending on the use case, or are they all kind of just basically using the graphical tool?

I think people still using flip around here and there. However, having the graphic part is the totally the big advantage for everyone. So there's a reason why from the day one, we created this great UI experience.

Because at Intuit in 2018, that was a little bit ahead of the journey for everyone adopting the Kubernetes in large scale. So Intuit basically asked us to say, "Hey, we want to adopting Kubernetes on AWS, and we have 4,000 developers. They don't know about Kubernetes at all.

" So our answer was Argo CD plus a nice user experience to be embedded. Then we don't need to tell the people, "Hey, what is a pod? What is a replica set?

" Okay, where you deployed, you see this tree viewThen you see, oh, I get it. So sure, I'm not the expert. You don't need to be the expert, but roughly you get it at least.

There is how the object are connected to each other. Additionally, we make the logs to be available, events to be available, and when something is broken, we highlight it. Okay, this part is crashing.

So in the end, is like we making the 4,000 developer to kind of self-educate themself. Rather than we are forcing a tutorial or we becoming the support team, we need to teaching them a lot of thing. In the end, it's like, okay, the education just happen like naturally.

Mm-hmm. It almost seems like Argo CD can be a higher level of abstraction above Kubernetes that makes the whole thing more accessible, and maybe democratizes this so that I can have folks who are mere mortals running this back-end process. I do think so.

Definitely, the Argo CD make the operate clusters in a larger scale way better, way better experience. I do think the... Okay, we keep hear that, oh, someone is running one cluster, two cluster, they said, "Hey," they're only using Argo CD.

But I rarely, rarely see anyone, they are running more than five cluster, they said they don't using Argo CD at all. That's the trend, yeah. Mm-hmm.

So where do we go from here? You can't walk down any of the aisles at the show without somebody talking about AI, so how does AI get applied to Argo CD and Cargo and everything else that we're doing? That's an excellent question.

So as the Acuity, we are actually providing the enterprise software delivery platform, so it's made of three capability. So Argo CD is powering our deployment, the Cargo is powering our promotion, so we do have something on top called Acuity Intelligence. So what does it do?

It's actually a purpose-built AI agent and for the software delivery, like operations. So it actually observe your infrastructure in the real time because as the Argo and the Cargo, we know what's going on with your infrastructure. We know the live logs, events, manifests, and deployment history, all the context we have.

And then it actually interprets incidents according the people to the runbooks and operational context. So we know when something bad happened, and then we can start and react to it. In the end, it's actually taking corrective action autonomously.

So all those experience are actually built inside your Argo and Cargo control plane, which is the tool that people already trust. So we basically bring the AI experience directly into the Argo and the Cargo, so people don't need to switch a different view or different tool. They can basically using Argo and Cargo, and they enjoy all the AI functionalities there.

Mm-hmm. How will this all play out in your mind then? Because as I look at it, each developer's going to have a bunch of AI agents, and they'll talk to each other- Right ...

and other developers, and then the software engineering team and the platform folks will have their AI agents. How does all this get orchestrated at the end of the day? What's going to be the thing that allows these AI agents to negotiate and kind of jointly accomplish a task and collaborate?

I think it's, in the end is we feel the AI is a little bit mimicking about how human are collaborate with each other in the end. So everyone have their different mission and different goals there. So means for the most of the developers, they are focused on doing the development.

Means I'm writing the code, I'm reviewing the code, I'm getting something like into build state. Then the platform team, the DevOps team, they are worried about more about, I want to deploy this successfully. But also afterwards, because the application's a living creature now.

Like something can be broken, crashing like in a day later. Then how do you kind of like babysit those applications properly? And also, security is like a dynamic like landscape, right?

Yesterday everything's fine. Today, okay, there is some like security breach or CVE happening. So there's a lot of the operational side about your application.

That's why I think that there is a mimic about how people are working, is every side of the role, we are getting more efficient by leveraging more AIs and more agent, a purpose-built agent to make them more efficient in the end. A lot of people seem to be worried that the developers will now be generating such a high volume of code that it will overwhelm the CD systems that they have or whatever they're using to promote and deploy software. Are we going to have to rethink this whole DevOps, GitOps- Yeah ...

revolution? It's a very accurate observation, actually. So, like we actually share some data, like publicly, like last week.

So last year, our customer did a 43 million deployment through our platform. I'm talking about our enterprise customers, not even just open source. Open source will be billion, for sure.

Mm-hmm. We do see that it was like 10 X compared with 2024 because of the AI adoption. So one of the observations really to the point is because of the AI, there is more development, more features, more fixes.

There's more things getting deployed to the production, to your environment in the end. So I do think it does causing more like a problem in the deployment side. That's why we need a more automation, more guardrail.

It's like, in the end is you want the AI actually also working for you in those contexts. For example, you want to deploy something, normally it's a human review. Like you cannot like review like 1,000 like deployment every day, but could you let an AI to doing some risk assessment about, hey, this is what I'm going to deploy.

This is what is running already in your production. What is the diff? Then the diff is, okay, you just change the documentation, then auto-approve.

Why bother, right? Just deploy, and that's fine. That is lower risk is fine because this a new API means not like changing the existing API, means the system should be still continue running, even the new API has some glitch, it's fine.

But okay, this is a massive refactoring. You are changing some existing API. That is definitely a medium or high risk that you want the human maybe in the loop to say, "Hey, double-check on this.

" Mm-hmm. So that's where I see the AI can already help to do more automation together with all the automation tools we have. That's the exactly the reason why we added the intelligence on top of our deployment and promotion solutions here.

So what is the future of the role of the software engineer and application developers for that matter? Because, there's still a lot of conversation out there about AI replacing people, but doesn't seem like that's necessarily the case, but what's your take? I think it's still very dynamic and a fluid situation right now.

It's like I see the AI as being embedded everywhere, so people will find the right balancing in the end. But I do think the AI will forcing the human to be more like a thinker, to be more like a leader, the leader of the agentic- Mm-hmm ... solutions, right?

So you are more like, rather than you doing a lot of, I would say, dirty job or low level thing, you are more like orchestrating the bigger picture. So what's your goal? How you breaking that bigger goal into 10 chewable steps to get there?

Then you are validate, okay, did AI getting this done in the high quality or to your expectation? Then you are doing the checkbox of those things. In the end, you reach your business goal properly or development goal properly.

I think that kind of forcing the human to doing more interesting job, to me, I would say, rather than, okay, what's the full loop? And how to reverse a linked list. It doesn't make sense to me.

Why you spend time to writing those software? Right. And do you think also maybe that more organizations will build custom software because with Argo we're making Kubernetes more accessible, and with AI, we're making it more accessible to do the coding.

So maybe I don't have to be a Global 2000 to build my own cloud native applications. I can be a mid-market company and succeed. Yeah, I do think that the software could be more customized.

There will be more customized built software, which I do think that will happen, but I don't take that as a bad thing for us, especially, because we thinking the Linux is a foundation for the operating system, Kubernetes is the foundation for the cloud operating system, and Argo CD is the deployment solution for all the Kubernetes or for the foundation. So what we are seeing that is, okay, sure, you're getting more customized software, but where they are running? So you still need to run on the Kubernetes, still running on the Linux, and you still need a deployment solution.

Actually, you need the deployment solution more urgently because you have so many you need to deploy and manage. So unless you basically are building a prototype you throw away, then you need to run it, you need to babysit it, you need the troubleshooting it. Mm-hmm.

So... So what do you see software engineering teams doing today that kind of just makes you shake your head a little bit and go, "Folks, maybe we want to be a little bit smarter than that"? I think the transition is already happening.

I talked with all my friends in Bay Area, Silicon Valley, so I do see their job responsibilities kind of being changing, I would say. " Spend the three days on it and trying to get it done, right? Now, because AI is doing more heavy lifting on coding, so their job is more around coordination, about reviewing, validation, and having the bigger picture.

So I don't know exactly what will happen in the three months later, to be honest, even or three years later. I think things will keep changing. We are very excited.

My team is already adopting a cloud code in a massive scale. I see a day and night difference already regarding the productivity. Yes.

And I do know we be cautious about the quality, which I do think that can be addressed with more AI involved and a more experienced engineer driving the process or driving the quality control on that. So it's exciting, but it's also changing, I would say. Mm-hmm.

So what is next for Argo CD and Kargo? As you look into the coming year, what's on your agenda? I think several things.

So we do think we want to still double down on the AI native side. I do think there are so many agentic, customized agent we can build for our customer to realize the value. Because I do thinking the platform team or the SRE team is on the relative conservative side for a good reason because, for example, if a $5 billion business is running on your platform, so you do want to be very cautious about how you run it, how you control it, how you operate it.

So I do think there is more deep dive, deep expertise agent should be built to getting more out of that AI experience to make more people more efficient in the AI and platform side. So on our side is also we want making our Kargo solution to be very generic and universal. Means we already supporting the Terraform now, supporting custom stacks, supporting VM, but we also want to bring the nice developer experience to the VM user, to the Terraform user, to the serverless users to make sure they're getting all the value out of the Kargo properly there.

So definitely a lot of work to do still. All right. Well, folks, you heard it here.

Argo, Kubernetes, Linux, they're all joined at the hip. Hey, thanks for coming by. Thank you for having me, Sam.

Thank you. All right. And we'll be back in a minute.