Excellent summary, I was just talking to somebody about this today so the timing is great. I think the Argo project is well positioned to be the revolution you talk about at the end. All it needs to do is integrate traces across all of its offerings since we can build the perfect CD process with Argo Workflows -> Argo CD -> Argo Rollouts -> Argo Workflows or whatever you need with Argo Events binding them together. I don't think this is a coincidence either 🙃
That's what I wanted and hope we'll get. Argo Events could have been the glue between Argo CD and Argo Workflows. Unfortunately, Argo Events is like an orphan no one wants to take care of.
@alioughana CDevents and the parent project cloudevents are certainly useful if you're building the solution yourself. Unfortunately, it's not widely accepted by other projects so there's quite some way to go before those become as widely used as, let's day, OpenTelemetry.
Good session. Imho: K8s is the holy grail of declarative state management continuously and autonomously, others that come and extend the impact domain of it for the entire solution stack, not the other way around. If a tool/new-ability has not born on/with k8s + k8s constructs it is subject to fail due to incompatibility over time , for me known example is jenkins as it has been failing for distributed scalability.
Question not related to the topic. How did you create and animate your graphics. Are they self drawn or did you use any tool for the presentation parts?
Thanks for another great video 🎉 I agree there is a lot of confusion on terminology and tools don't help here. In my opinion a good developer portal implementation should at least give you information about your desired state status and maybe correlated to their corresponding one shot actions. Not in real time, but it should be close what one should expect to have "under control" in a single place
Hi Victor, on the same vein of GitOps, how would you reconcile a cluster migration or disaster recovery through a tool like Velero with the GitOps paradigm? Thank you for your incredible content on this niche :)
You can continuously deploy releases to production without any verification. Still, that is not CD and, even if it would be, no one is practicing it since those that do are probably already bankrupt.
That would be like saying "If Ubuntu is Linux kernel plus a package manager and a few preinstalled apps, then if kernel is nothing, we are left with a package manager and a few preinstalled apps."
I still don't understand why we need to have a process to continuosly monitor prod/qa/whatever environment state if we always follow best practices and we don't make manual changes. If we do isn't it that the problem is elsewhere? And if so.. still... gitops won't help you because you can still have manual changes not detected by gitpos that can screw up your entire infrastructure. Said that... I'm still not fully convinced on gitops . Convince me otherwise please I beg you
@@DevOpsToolkit mmm not sure if I follow you. I use kubernetes because is a cloud independent, container orchestration solution (among many other things)... not because it does drift detection and reconciliation. Getting back to the point... if I deploy a helm chart that deploys multiple ingress , deployments, hpas, secrets, configmaps, etc etc etc, you chose... and the cluster changes are allowed exclusively only through my CI / CD pipeline process... why do I need a process to continuosly monitor the state. And on my second point... if someone put his hands on a cluster and start to create resources out of the scope of gitops but that will interfeer with my application normal operation... how gitops can help me on that situation.
@juanbreinlinger if you don't need drift detection and reconciliation one of the reasons to adopt gitops is gone. The other might be that it is a pull based model meaning that your clusters can be locked (more secure). Th way I see it, gitops works well because it follows kubernetes patterns which might or might not be useful to all. As a side note, Helm is probably the most adopted yet the worst solution to define data.
@juanbreinlinger @juanbreinlinger i forgot to comments on the second question... If you do use gitops, your normal mode of operations becomes gitops (pushing the desired state to git). The actual state will be th same as the desired state, no matter what or who does something in your clusters and you will have a historical record of all the intentions.
@juanbreinlinger the question we should be asking is whether desired state in etcd is enough or we need it in git as well. That's a tougher one to answer.
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
I have to admit, I watched the video 2 times in order to understand the one shot vs the continous process paradigma, good work Viktor
Thank you. Very good explanation. Kind of knew all this, but having it laid out clearly and explained helped me grasp it even better.
Excellent summary, I was just talking to somebody about this today so the timing is great.
I think the Argo project is well positioned to be the revolution you talk about at the end. All it needs to do is integrate traces across all of its offerings since we can build the perfect CD process with Argo Workflows -> Argo CD -> Argo Rollouts -> Argo Workflows or whatever you need with Argo Events binding them together. I don't think this is a coincidence either 🙃
That's what I wanted and hope we'll get. Argo Events could have been the glue between Argo CD and Argo Workflows. Unfortunately, Argo Events is like an orphan no one wants to take care of.
@@DevOpsToolkit what about CDEvents? Do you think that. can become a useful component in a potential solution?
@alioughana CDevents and the parent project cloudevents are certainly useful if you're building the solution yourself. Unfortunately, it's not widely accepted by other projects so there's quite some way to go before those become as widely used as, let's day, OpenTelemetry.
Good session. Imho: K8s is the holy grail of declarative state management continuously and autonomously, others that come and extend the impact domain of it for the entire solution stack, not the other way around. If a tool/new-ability has not born on/with k8s + k8s constructs it is subject to fail due to incompatibility over time , for me known example is jenkins as it has been failing for distributed scalability.
Good point with observability tooling. Do you have any state-of-art OSS tools/ predefined Grafana dashboards you recommend for this?
I don't have any dashboards I can share as-is. I will do my best to clean up some of those i do have so that I can make them public.
Question not related to the topic. How did you create and animate your graphics. Are they self drawn or did you use any tool for the presentation parts?
If you're referring to diagrams, they were drawn on iPad.
Thanks for another great video 🎉 I agree there is a lot of confusion on terminology and tools don't help here. In my opinion a good developer portal implementation should at least give you information about your desired state status and maybe correlated to their corresponding one shot actions. Not in real time, but it should be close what one should expect to have "under control" in a single place
Hi Victor, on the same vein of GitOps, how would you reconcile a cluster migration or disaster recovery through a tool like Velero with the GitOps paradigm?
Thank you for your incredible content on this niche :)
I'll add velero to my to-do list and make sure that it contains a section related to gitops.
Great explation thanks, but if could be more pictorial/ diagram and flows
I'd argue you technically can be doing CD w/o CI, its just a really bad idea
You can continuously deploy releases to production without any verification. Still, that is not CD and, even if it would be, no one is practicing it since those that do are probably already bankrupt.
@@DevOpsToolkit That is fair, "safely" is really a built in clause to the common CD definitions
If CD is CI and a little bit more, then if your CI is nothing, CD is what's left :)
Which I agree is a bad idea.
That would be like saying "If Ubuntu is Linux kernel plus a package manager and a few preinstalled apps, then if kernel is nothing, we are left with a package manager and a few preinstalled apps."
Thank you...challenge is how to develop a robot to perform all these tasks with ease, if fails, to rectify itself....thanks
I still don't understand why we need to have a process to continuosly monitor prod/qa/whatever environment state if we always follow best practices and we don't make manual changes. If we do isn't it that the problem is elsewhere? And if so.. still... gitops won't help you because you can still have manual changes not detected by gitpos that can screw up your entire infrastructure. Said that... I'm still not fully convinced on gitops . Convince me otherwise please I beg you
That would mean that kubernetes itself is not a good choice for you since it also does continuous drift detection and reconciliation.
@@DevOpsToolkit mmm not sure if I follow you. I use kubernetes because is a cloud independent, container orchestration solution (among many other things)... not because it does drift detection and reconciliation.
Getting back to the point... if I deploy a helm chart that deploys multiple ingress , deployments, hpas, secrets, configmaps, etc etc etc, you chose... and the cluster changes are allowed exclusively only through my CI / CD pipeline process... why do I need a process to continuosly monitor the state.
And on my second point... if someone put his hands on a cluster and start to create resources out of the scope of gitops but that will interfeer with my application normal operation... how gitops can help me on that situation.
@juanbreinlinger if you don't need drift detection and reconciliation one of the reasons to adopt gitops is gone. The other might be that it is a pull based model meaning that your clusters can be locked (more secure).
Th way I see it, gitops works well because it follows kubernetes patterns which might or might not be useful to all.
As a side note, Helm is probably the most adopted yet the worst solution to define data.
@juanbreinlinger @juanbreinlinger i forgot to comments on the second question... If you do use gitops, your normal mode of operations becomes gitops (pushing the desired state to git). The actual state will be th same as the desired state, no matter what or who does something in your clusters and you will have a historical record of all the intentions.
@juanbreinlinger the question we should be asking is whether desired state in etcd is enough or we need it in git as well. That's a tougher one to answer.