Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kargo, a multi-stage application lifecycle orchestrator

akuity.io

Post reply on HN
Print view View original

21–30 of 83 posts

Re: Kargo, a multi-stage application lifecycle orchestrator

#21

Post by therealkrancour »

nickjj wrote: post #13

What about having a git repo that has a Kustomize base which has overlays for different environments? This way each environment is in its own directory which can have its own patches such as using a private load balancer instead of public for a staging environment or setting whatever environment variables that need to be different. Then at the Argo CD level, Argo CD running in prod will look for an Application in the…

I am a lead on Kargo. That's a great approach you've described and Kargo helps you make that approach work even better. It's not trying to re-solve problems that are already solved well by config management tools or by Argo CD. It provides a higher layer that integrates with those to orchestrate the progression of changes from one environment to another...

So in your example, suppose you changed something in your Kustomize `base/` directory. With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment.

Re: Kargo, a multi-stage application lifecycle orchestrator

#22

Post by therealkrancour »

Havoc wrote: post #14

Sounds promising. Vaguely terraform like in its application to outside subscription services. Can’t say I’m a fan of “we call it freight” though. Artefact is a perfectly fine word.

Freight often contains multiple artifacts. Container would have been a nice word, but it's taken. ;)

Re: Kargo, a multi-stage application lifecycle orchestrator

#23

Post by greatfood230 »

rjzzleep wrote: post #18

I've used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won't be accounted for. I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath. Ps. when I first…

Agreed. But I do feel Argo gives a good foundation; something on top is highly anticipated.

Re: Kargo, a multi-stage application lifecycle orchestrator

#24

Post by nickjj »

therealkrancour wrote: post #21
nickjj wrote: post #13

What about having a git repo that has a Kustomize base which has overlays for different environments? This way each environment is in its own directory which can have its own patches such as using a private load balancer instead of public for a staging environment or setting whatever environment variables that need to be different. Then at the Argo CD level, Argo CD running in prod will look for an Application in the…

I am a lead on Kargo. That's a great approach you've described and Kargo helps you make that approach work even better. It's not trying to re-solve problems that are already solved well by config management tools or by Argo CD. It provides a higher layer that integrates with those to orchestrate the progression of changes from one environment to another... So in your example, suppose you changed something in your Kus…

> With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment.

In prod it wouldn't get rolled out until someone manually clicks the sync button for each app in that environment. But yes, in staging it would get AutoSync'd to all of the apps. I get what you're saying though.

It will be curious to see how Kargo works across multiple clusters in the staging vs prod example where both clusters each have their own Argo CD instance running but you want to view and promote an artifact across N clusters.

In any case, I'll give it a look when it's available to see how it can improve my current workflows. Overall I'm really happy I started using Argo CD ~2 years ago.

Re: Kargo, a multi-stage application lifecycle orchestrator

#25

Post by therealkrancour »

bingemaker wrote: post #8

Is this tool similar to https://dagger.io/ ?

Not much overlap. Dagger wasn't on my radar until now, but it reminds me of something else I used to work on and it frankly looks awesome!

But it looks to allow you to defines pipelines using your preferred imperative programming language -- which is awesome. I would totally use that for CI.

Kargo is really about divorcing CI and CD and creating something that's actually CD-focused and compatible with established GitOps principles.

Re: Kargo, a multi-stage application lifecycle orchestrator

#26

Post by candiddevmike »

rjzzleep wrote: post #18

I've used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won't be accounted for. I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath. Ps. when I first…

Akuity is getting their lunch eaten by Harness and need some kind of IP to sell besides Argo-as-a-Service. I don't really see a path forward for them in the very crowded CI/CD space, so I would wait to see how they will monetize this and who the first movers are before attempting to use it.

From a business standpoint, Akuity had their Series A in 2022 and raised $25M. They have yet to show up on anyone's radar, IMO. Maybe Kargo is their PMF but I wouldn't move my CI/CD over yet.

Re: Kargo, a multi-stage application lifecycle orchestrator

#28

Post by morey-tech »

rjzzleep wrote: post #18

I've used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won't be accounted for. I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I'm not holding my breath. Ps. when I first…

Some of that is a challenge of product design.

Devs tend to be opinionated on these projects because without that you end up with feature sprawl to the point that projects become unmaintainable.

On the other side, new projects need to focus on their specific segment and solve that problem well without worrying about corner cases.

Either way, any solution for a corner case needs to be implemented in a way that solves it broadly for any user.

Re: Kargo, a multi-stage application lifecycle orchestrator

#29

Post by ThinkBeat »

I can almost follow this but I am at the edge of where I see how it could sound like buzzword gibberish.

I dont blame the author(s) but things are getting more specialized and more terms are created. (which usually maps to an existing term which also maps to an existed term which also maps an existing term and so on.

I have though about trying to create a "terminator"(hah) where you can paste in something from a new product and it will map the terms to existing terms as a sort of translator or term machine.

"" We are thrilled to announce Kargo, a multi-stage application lifecycle orchestrator for continuously delivering and promoting changes through environments. Kargo, brought to you by the creators of the Argo Project, is a reimagining of CD pipelines for the cloud-native era, with first-class GitOps support, progressive delivery features, and is 100% open source. ""

Re: Kargo, a multi-stage application lifecycle orchestrator

#30

Post by therealkrancour »

nickjj wrote: post #24
therealkrancour wrote: post #21

Earlier quoted context omitted.

I am a lead on Kargo. That's a great approach you've described and Kargo helps you make that approach work even better. It's not trying to re-solve problems that are already solved well by config management tools or by Argo CD. It provides a higher layer that integrates with those to orchestrate the progression of changes from one environment to another... So in your example, suppose you changed something in your Kus…

> With _just_ Kustomize and Argo CD, those changes roll out to all environments all at once. With Kargo, you can progress the change and (re-)validate it environment-by-environment. In prod it wouldn't get rolled out until someone manually clicks the sync button for each app in that environment. But yes, in staging it would get AutoSync'd to all of the apps. I get what you're saying though. It will be curious to see…

> In prod it wouldn't get rolled out until someone manually clicks the sync button

That's a great point and if that works for you, awesome! Note though that relies on the state of the prod Application to temporarily contradict the source of truth that is your repo. If you lose that prod Application and re-create it, prod will be in a state you hadn't yet blessed.

Post reply on HN