I had the good fortune to work with Akuity last year. I haven’t looked at Kargo yet but I’m sure it’s going to be solid based on my experience with their engineering and leadership. The problem it is trying to solve for is very real and historically expensive to solve for. Most companies that operate in multiple clusters and want to do GitOps will face this issue, especially when there are gates and approvals that happen between environments.
Kargo, a multi-stage application lifecycle orchestrator
71–80 of 83 posts
Re: Kargo, a multi-stage application lifecycle orchestrator
#72It sounds like the solution all of us knew Argo needed to solve but didn't. I'm... hopeful? But besides the fact that it's not finished yet, it also sounds like it's going to be tightly integrated into their "Akuity Platform". Tightly integrated solutions are an anti-pattern; we'll end up with cobbled-together scripts again when something we need to do isn't allowed by the "opinionated" platform.
Re: Kargo, a multi-stage application lifecycle orchestrator
#73> Unlike CI, Kargo deployment pipelines are not generic “jobs” (...). Instead, Kargo Stages are used to model your environments (...) I didn't see an explanation of how Stages are different than jobs. Every single usage of Stage could have been replaced with job and the meaning would stay the same. The data and DevOps marketing people really need to drop the buzzwordism.
I am a fan of the term- after long naming wars internally we settled on promotion stage to signify the same concept. It is one or more targeted clusters that function as one of several environments. It works both in the sense of stage as venue and stage as phase. Teams promote their config from something like dev to QA to Preprod to Prod. Often there is a need for business logic to happen before advancing to another stage, or multiple environments in different regions that need to be healthy within a stage before promotion can happen.
Job doesn’t really encapsulate this at all. An alternative may be Metaenvironments.
Re: Kargo, a multi-stage application lifecycle orchestrator
#74> Unlike CI, Kargo deployment pipelines are not generic “jobs” (...). Instead, Kargo Stages are used to model your environments (...) I didn't see an explanation of how Stages are different than jobs. Every single usage of Stage could have been replaced with job and the meaning would stay the same. The data and DevOps marketing people really need to drop the buzzwordism.
Stages are just quality gates. When the quality level is high enough, the gate is released and the next step in the pipeline is performed.
Re: Kargo, a multi-stage application lifecycle orchestrator
#75I 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…
multi-stage: in this case they mean dev->test->prod
application lifecycle: CI & CD
orchestrator: a thing that runs jobs with dependencies
continuously delivering: CD
promoting changes: if the tests work in the staging environment, allow someone to click a button that says "deploy to prod"
environments: dev, test, staging, production
CD pipelines: a bunch of continuous delivery jobs
cloud-native era: microservices/SaaS/PaaS/IaaS/IaC/II/containerization/webhooks/OIDC
first-class GitOps support: if you push a commit, a job is run
progressive delivery: deploy to 10% of users, if lots of errors, roll back the deploy
100% open source: our code is [currently] available but we will charge you out the ass to manage it for you and Enterprise features will be locked up once we write them
Re: Kargo, a multi-stage application lifecycle orchestrator
#76I'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…
I think that's the nature of any CI/CD tool out there. All of them have some opinion to bound the product otherwise it is very hard to tame usecases.
Re: Kargo, a multi-stage application lifecycle orchestrator
#77What 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…
We faced that (and are facing it today) with Helm chart updates.
In our current setup it's not possible to rollout a new version of an Helm chart in dev, then in staging and finally in prod (without causing an out of sync state.
The rest is managed via values-$env.yaml, which works perfectly fine
Re: Kargo, a multi-stage application lifecycle orchestrator
#78Earlier quoted context omitted.
I feel like Im missing something obvious but… cloudformation does lock you into aws, doesn’t it?
It totally does. And it's an interesting argument when things like Terraform exist.
Migrating from AWS to othercloud isn't really going to be about converting your CloudFormation stacks to something new (TF or otherwise), because that's the least of your concerns.
If you had Terraform-defined infrastructure for AWS you'll still need to define entirely different infrastructure for othercloud. Starting with Terraform is going to be marginally easier because maybe you intelligently organized your code using the tools Terraform offers (didn't you?), and didn't just materialize it all as a big pile of root modules (or worse, root modules instantiated by running with different var arguments--you didn't do that, did you?). Because with Terraform you can do some code reuse, etc. in a way you can't with CloudFormation.
But it's only going to be easier because you already know the language and because you have less code (maybe) to examine to inspire your new code base[1]. All your resources will be different and will mostly behave differently as well, so it's not a matter of renaming but of rearchitecture anyway.
----- [1] Well, the third thing that's going to be easier is that you'll understand the DIY aspects of actually running your Terraform, since it's not a service like CloudFormation. Wrangling states and so forth.
Re: Kargo, a multi-stage application lifecycle orchestrator
#79Earlier quoted context omitted.
I don't understand one thing about GitOps. Imagine 10 apps deployed. All are actively deployed let's say few times a day. You want to go back 10 days for App A. But in doing so you would have reverted whole state and all apps as they were 10 days ago. Only way is to cherry pick particular commit and revert it. No? I mean how git can be useful in rolling back singel components back and forth?
To restore app A to a given state, you add git commits that specify the desired state of app A.
Basically, much of git's time traveling functionality is not of much use.
Re: Kargo, a multi-stage application lifecycle orchestrator
#80Earlier quoted context omitted.
I don't understand one thing about GitOps. Imagine 10 apps deployed. All are actively deployed let's say few times a day. You want to go back 10 days for App A. But in doing so you would have reverted whole state and all apps as they were 10 days ago. Only way is to cherry pick particular commit and revert it. No? I mean how git can be useful in rolling back singel components back and forth?
Personally I like to treat the Git in GitOps as an implementation detail. The underlying principle of GitOps is that your entire environments setup and config is written in code, and version controlled. So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash. Then there’s the whole constant reconciliation of your version controlled…
Thank you for the insights. Last part specifically. I also feel something is surely amiss.