Ortelius Open Source Beaming Ortelius Podcast, 14 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introduction to GitOps, Argo CD, and Flux

Description

Join Viktor Farcic and Saim Safder on a discussion about GitOps, what it is, why it's cool, and how you can get started on a GitOps journey. -- Watch live at https://www.twitch.tv/orteliusos

A

Thank you, everyone for joining us on ortelius, beaming, hoteliers, podcast and let me fix, introduce you. What totally is is this is help you build some of the micro services by providing you a central catalog for services with their deployments, specs applications teams can easily consume and deploy services across cluster hotelies track application version based on service updates and map, their service dependency, eliminating confusion and guess work. So some small intro of the ateliers, and now we are talking about on this episode, get offs and we have not a better guest than victor forsek.

A

Thank you very much victor for joining us.

B

Hey good to be here again.

A

Yes, absolutely so just a quick, quick introduction of yours to people who are listening to us on the podcast.

B

A

B

Know I do a lot a lot, a bunch of things, the different things.

A

Yes, absolutely absolutely victory that dwells advocate at about, and he has a wonderful youtube channel, always try to share his wonderful work with the community and a great human being, and I I just ask him: I want to have some show with you and he's absolutely ready to do it. So today's our agenda is get offs and people who had never heard about get offs. Let us let people know what it is and why we are so crazy about skatops.

B

So there are two different things that I I believe that might need. Explanation, first, is what it really is, and then there are principles which are, I think, very important, because if you just talk about what it is, then you might think that many tools are doing githubs, even if they're not right. So what did this is relatively easy to explain and that's that we have two states desired state. That's what I want as a human being as victor kind of like that's what that's the expression of my desire and we have the actual state.

B

That's what something really is right. So it's what it should be and what it is and what it should be is defined one way or another is something that is readable by machines, starting it. That's where we store things. It doesn't have to be git.

B

To be honest, it can be svn, it can be database but stored somewhere, and then we have uh and then that the actual state, let's say aws resources or kubernetes applications or databases or whatever it is needs to somehow become uh get into the same state as the desired state is what I defined myself.

B

So gitops is all about converging the actual state into the desired state. uh This. What I want- and it needs to be this and what it is must be. The same is what I want now.

B

That being said, there are four principles, because, according to that definition, what I just said you can say hey uh if I use circle, ci or jenkins or gitlab ci or any of those things I'm doing githubs right, because I push something to get and then uh those pipelines do something and then all of a sudden, my actual state is, as I want right, according to that.

B

What I just said and that's why the principles are extremely important right and there are four principles that any tool needs to implement in order to be called gitos right uh and by the way I didn't mention before. But there are tools in between the actual and desired state that are making this happen. It's not uh little people sitting around and waiting uh doing our biddings, so four principles right needs to be decorative, meaning that uh the desired state needs to be expressed. Declaratively now just to clarify before I continue.

B

What I'm saying does not necessarily mean that that's the best way to do stuff, I'm just saying that that's how something should be done to be called githubs. That does not mean that you need to define declarativity, you don't have to use githubs right, so declarative definition of the desired state.

B

It needs to be versioned and immutable, so you cannot just keep it on this drive right. That's why I said git git is the most common way, how we version things and how we make something immutable, meaning uh you cannot really edit the comment you can create a new comment. You cannot edit it and now comes the important thing that distinguishes github stools from pipelines. It needs to be pulled automatically.

B

And that means that you cannot have hey, I push something to git, and then I run gitlab ci. I because git github is going to notify it. That's push mechanism right, it is to be pulled, so I have, I must have a process somewhere that is constantly monitoring my git repository and whenever there is a change in between what it is and what it should be does whatever needs to be done so pull the automatically third and the fourth one continuously reconciled, and this is now important, even if ignore pulled automatically.

B

It's not good enough to say hey whenever I change something you get, I will run some process and that process will do whatever needs to be done. No, because that actual state might change, because a server might go down for random reasons right so and then, if it goes down, it will stay down forever.

B

Until I make a change to get that's why it needs to be continuously reconciled, we need to have a process that is all the time watching for the differences, not only when I push something to get, but all the time monitoring and saying is it is that is this the same as this? Yes, is this the same as this? Yes, is this the same as this? No okay. Stop. I need to do something right, so declarative version that immutable pulled automatically continuously reconciled. If you do those four things, you're doing githubs.

A

Yes, absolutely absolutely that's a great way of thinking about gate house, because it's not really complicated at it at the first go, but, incidentally, is like you have yaml files that you have in your machine and kubernetes is all about yaml. You have ingress for yammer, you have services for yammer, you have deployments replica, everything is yaml based and when you put this yaml into the github repository, if their job is actually to make this make the system to the desired state. You want to rapidly guys you want.

A

You have to ingress, install on that application, and you want to have the self-healing like some of the parts go down, it's ultimately stayed up and the one of the best things that you draw during the conversation is reconciling.

A

So I think that's that that is, I think, the main part of the get offs so tell us about what reconciling is and also there are some confused some people who are relatively new. What is imperative and declarative approach in general in it.

B

I'll ask those questions, but before I do that a small correction of what you said, I intentionally did not say kubernetes you did and I'm intentionally avoiding to say kubernetes, because nothing says that we should apply github's principles only for applications running kubernetes. It could be for anything okay. So, and now I already forgot to your questions. What was a? What is reconcile, because uh what does it mean being reconciled right.

A

B

A

B

No, I'm going to actually use kubernetes example right when you deploy a deployment in kubernetes uh you're telling kubernetes. I want this deployment and, as a result of- and you say I want this deployment and I want to have two replicas of my application right, I'm not talking about githubs for now right.

B

What kubernetes does is two things. First, it will create two pods so that you have two replicas of your application, but- and this is now kind of a reconciliation comes into- it- does not only create those two pods. First, it checks how many pods do you have zero one? Three right, it might create two, it might create one it might create, uh it might destroy a pod right and it is continuously watching the status.

B

It's not only doing something once it is you're making a contract like with a signature kind of saying I told you two pods, I told you two replicas and I want you to ensure that it's always too replicas, no matter what happens right and that's reconciliation, uh I mean not directly, but basically, reconciliation is about. Looking for drifts.

B

Drifts means the differences between what I want and what there is, if they're, if they're not the same, then there is a drift like hey.

B

This tiny thing is different than than what you said and when it finds drifts it reconciles, meaning that it is eliminating those drifts, those differences by reconciling those two states, that's what kubernetes does and that's one of the reasons why all the uh github stools worth using today are in kubernetes, because kubernetes already has half of the work for github tools done, so reconciliation is removing the drifts and drifts are differences between two states, and you ask me a second question, but I forgot what it was. Yes.

A

Absolutely absolutely and that that is actually based on that reconciliation. We talked about a lot in kubernetes world declaratively and for the people who are really new to this world. What does you mean? Because we have two way of doing things in id in in general, like one is imperatively and one is declaratively, and I want you to uh people know what that two different mean, and that is based on the consideration we have like reconciliation and drift detection.

B

Yes, so uh for kubernetes to know for kubernetes or github tools or many other types of tools to know easily what you want. uh It's actually not to know it's much easier for them to know what you want. If you declared every single piece of what that is right, uh it's much easier for kubernetes to understand what you want when you say. I want three replicas and I want this host and I want this and I want that right uh in the declaring each uh parameter of something and each component separately right imperative would be.

B

uh Basically, you know using programming languages, saying hey. I have some if else statements and I have loops- and I have all the things that we do when we write real code whatever that means. Actually everything is real code, but application code.

B

So imperative is more about creating the logic of something and declarative is about exactly specifying what you want and that's very important, because that's that makes job of kubernetes easy right now. You can have both to clarify, so you can use something like uh templating. Some people say that helm is declarative. I I I beg to differ. I say that helm is actually imperative, uh but or python code or go code. You don't have to do it decoratively.

B

However, you can specify any way you want, but between you doing something and that reaching kubernetes or github stools it needs to be transformed into declarative.

B

So you have two options: either you write directly yaml or json or xml, or any of the declarative base to define things directly or you can use some other tools. You can use like, let's say polumi.

B

But for pollumi to do what needs to be done. Pollumi then needs to transform what you did into a declarative format, and then it can be used by githubs by kubernetes and many other tools. So how you get to have declarative is up to you, but it needs to be declared one way or another. At the end of the day,.

A

Yes, absolutely absolutely like. I think that the one way you do manually some of the stuff- and you tell the system that I want my system to have in that stage that I have defined in yaml. I don't know how you do it. Let's do it. You know how to do it. So that's you. That's the way to do it and apparently you're telling each step like you've done this script. You've done this and load balancer you've done this thing, so I think that's something a great explanation to this.

A

I think that's a very really new everybody. Listening to this. Actually they heard about a lot declaratively imperatively.

B

Yeah kind of like you know the example would be, and I'm using this example simply because that's what I was doing an hour ago, right uh example from my life an hour ago, I was doing homework with my daughter right at one moment. I talked to her. Do the homework, that's about it very clear, concise!

B

That's what needs to be done right. I did not go and say hey, do this and then do that and loop through it and stuff like that, it needs to have very clear instructions. What should be done? That's necessary right.

A

Yes, absolutely absolutely, and also, I think, for those of people might be some of the people who are joining or listening to us. It hasn't been devops background, like they spend most of the career in the devops and they hot they heard the coin in the new term called get offs and they're wondering. Is it a subset of devops? What is a completely new field, or how do I map my existing knowledge of devops into the githubs.

B

So uh I I still don't know what devops is to begin with.

A

B

Is everything whatever you ask? Somebody is this devops? Yes, absolutely everything right uh so uh devops is about is a maybe a process. It's a cultural change and stuff like that right. Well, uh it's something very fluid hard to define. uh Github's is a technical practice right, so devops is not a technical practice. It's not kind of like you do this and then your devops, no kind of like developers and operations work together, blah blah blah like agile conceptually, it's not the same thing, but it goes into the same category.

B

As you say, agile, agile is not a technical practice. Right. uh Xp is the same thing with github. Githubs is a technical practice. This is what needs to be done. This is how that something is done, and those are the tools that fulfill the requirements to do things in a very, very specific way right. So technical devops is, I still don't know what it is, but it's not the technical term for sure.

A

Yes, absolutely absolutely- and I I think, as you mentioned like one is, is a kind of a specification like you should do these kind of thing in the devops world and there are plethora of tools, and this is all totally up to you. How do you implement those things? I know the guitar.

B

A

Actually, a technical term- and this is a this- is your problem you have, and this is how you technically solve that problem, and now we're talking about the github. So people are very listening to us and new. Tell us about the workflow, because that's really important for the people to understand from the vectors vector-wise like what the workflow it is like when we develop code and when you commit the first repository first say to commit to the repository what happened next in the githubs pipeline? How should you build it and what the process look like.

B

So I I will actually give you two answers to that. uh Well, actually only one answer to what you ask but then say that you, you ask the wrong question so get those processes very easy. You push some change to get that defines that modifies the desired state. There is a process running somewhere that detects that and makes the changes to the system and continues monitoring the system.

B

There is not much more to it or, to put it in other words, you change, yaml or json or whatever file you push it to git and that's the whole process that there's nothing else to it. Right I mean from the human perspective from process perspective we have some operator kind of that is monitoring it sees. Oh victor wants a new change, the desired state. I should do something now. What is a more interesting question which you didn't ask uh from my perspective is what is the?

B

How does github fix fit into continuous delivery or continuous integration or continuous deployment process? Right to me, that's a more interesting question now, if you look at forget about github's, imagine that it doesn't exist kind of how we did in the past. So uh if you talk about cicd every, uh let's say a cd, continuous delivery right. Continuous delivery is a full automation of the life cycle of an application, and what that really means is that it starts with git. I push some change to git and now bear in mind.

B

When I say change, I do not necessarily mean change to the state of my system. It could be changed to my python code. Doesn't matter, I push something to get.

B

I typic typically run a pipeline that would build test, deploy and so on and so forth. What it does depends from one case to another, but let's say in simple way: build test, deploy right now in that world the deployment build would be okay, I execute like from inside pipeline, not me right in a pipeline. I would execute something similar to docker docker image, build test. I would execute some maven tests or whatever you're using and deployment would be cube. Cattle apply right or helmet stall or ssh over there and copy the file.

B

Whatever the deployment process is now, if you put githubs into the mix, the situation changes a bit uh and it changes. uh If I still continue with those three steps right, I build stays the same. I test stays the same and then when it comes to deployment instead of deploying directly from the pipeline, I'm actually that pipeline is not going to deploy anything. That pipeline is going to get the contents of the repository that contains my manifest modify, something let's say: change the tag of the image of the application and push it back to git.

B

So my pipelines, all of a sudden, do not deploy anything. They are modifying git repositories, it doesn't have to be pipeline. We have other ways to do that, but, let's say pipeline for the argument right and then pipeline from from pipeline perspective. It's finished, but the process perspective is not finished right after my pipeline is finished, then we have like flux or argo cd that will detect that change applied to the cluster or aws or wherever you're running right.

B

So the from the high level perspective is still the same. We built the uh test will deploy, but the way how we deploy is different. We do not deploy directly, we make changes to get and the reasons why we want to do that. Actually, the more I forgot about the most important thing to say right: why do we want githubs in the first place, and the reason is that I want to be able to have information at any given moment?

B

What is supposed to be the state of my system?

B

If you just execute cube cattle apply, it doesn't matter whether you do it from my laptop or I do it from pipelines, then kind of like nobody knows what what's?

B

What is the state that you want to have, and I don't mean on that release, but the state is the kind of everything, so we want to track those things and that's why the whole story about github's right.

A

Yes, absolutely absolutely and you'd, but I think you get my question because the next question actually on the cicd like how it's, depending on.

B

A

And you already answered that that's awesome. So now we kick start the moving forward, because we already uh we you talk about like argo, cd and flux. You talk during the conversation and for the people we talk about get offs. We know what it is and how it's detected drift detection and how it's different for the current ci cd pipeline, but now the current implementation we have like in orgo, cd and flux, so tell us people uh how what these tools are doing and how they. Actually you get started with this dualism as well.

B

So uh what they're doing is relatively easy to explain: it's, not necessarily that what they're doing is easy, it's not, but to explain it is relatively. Is you have a process running somewhere in kubernetes cluster right? uh It doesn't have to be kubernetes cluster, but all the tools happen to be in kubernetes, because most of the innovation is happening kubernetes. So we have a process running in kubernetes and all we are doing is telling fluxopargo cd, hey here's an application, and by application I do not mean necessarily the same thing as application application.

B

I mean here's a uh entity, let's say entity, here's an entity that I want you to manage and that entity or entities in plural are defined in this repository. So we are feeding argos, idiot flux within with information two types of information. First, these are the repositories you should watch and the second thing is those are the destinations where that something should be happening. Right kind of hey uh inside of whatever is defined in that repository should run inside of this cluster, or it doesn't have to be application right.

B

It could be should be something running in aws right or in azure or whatever so source desired. State git destination could be provider like azure.

B

So does we just feed it that information and that's about it right and then it's up to those tools to figure out what you have in those repositories and uh how different that is from what is in the destination locations.

A

Yes, absolutely absolutely so we have a you, have a source like you tell. This is where my code is living, and this is my desired destination. Is I want my system to look like this at any moment of time and.

B

Always forever.

A

Forever- and this is your job is actually to make that system into that state. I don't.

B

A

You tell it how you make it happen. It's totally. The job of yours now do that. So it's not.

B

My problem, yes, absolutely.

A

It's now the life is really easy. Explanation is really easy, but how these uh system, like argo cd flux, because in the kubernetes landscape there is always debates about what should we do, because there is so many so many options you have and I think, with the github's words there are so many might be. There are few many, but we have I'll talk about a lot: argo, cd and flux. So now we talk about what the difference is and it is different to understand what is matter, but it's different.

A

What how it's actually different from each other.

B

So uh let's say there are three tools that are worth considering: argo, cd flux and newcomer rancher fleet. Everything else is either doesn't exist or it's not github's or it's too young. Now I'm going to ignore entrepreneurs for a second right.

B

uh The way how I like to describe uh the differences between uh argo, cd and rancher, sorry and the flux is like uh the situation after the second world war during cold war right, so what was happening during cold war? You know russia and u.s, eastern and western blocs.

B

Whenever somebody increases the number of missiles, the other side does the same right and that was kind of like exact, so kind of it was a phrase where bo the moment. One side goes in front. The other side would catch up right and it's something similar with the argoncidium flux.

B

Now, of course, there are differences really, but for ignoring now slightly different way to define things you know manifest they are more or less the same right I mean there are differences just to clarify I'm not saying that they are exactly the same, but from user perspective, 95 or 90 of what they do is really the same.

B

The major big difference, I think, uh if I would have to specify one big difference, uh is that targo cd has a web. Ui and flux doesn't free option, I'm talking about open source, ignoring enterprise version, but apart from that choose either of the two uh throw a coin kind of head stale and choose one.

A

Yes, absolutely absolutely, and also if you are still new and don't know where what which one to use the victor has a wonderful youtube channel and I think ton of videos on githubs and flux will tell you in which scenario you should use that go check that out as well. I don't think if you're not subscribing to the victor channel, I think you're, not in the cloud native word. You sure you should be. Is this? It's been a wonderful youtube.

B

If you're not subscribed, I will find you.

A

B

Punish you, I know who you are, I know who you are. I know you er.

A

Yes, absolutely absolutely go go check. This is a wonderful place because I always always even see very new terminologies new concepts, new tools, I the only channel I have here. I can see all the new details around the things I never heard about it and explains victor's playing wonderfully well in a very short format in this app, and we talk about like talk about flux, argo cd.

A

Now, as you turn the coin like when you start another conversation, but before we move into that talk about some ratchet fleet, because it's had, I think it's it's it's uh it's been in in this stage. Now that we can't talk about it, it has.

B

A

Good implications.

B

Yeah, so what makes rancher fleets special is that it was designed to run a scale or not to run a scale. Sorry, that's not correct. It was designed to manage your state at scale right so from design perspective, it was made from get go to effectively manage applications running in dozens or hundreds of clusters right and hundreds of or thousands of applications stuff like so it's at scale.

B

Now that's design right! That's what makes it special we're designed to run a scale now. Do not misunderstand what I'm saying, because I'm in no way saying that argosy or flags do not manage applications and resources at scale they do, but they were not designed from day one to do that right.

B

So I would consider rancher fleet, if you want to run your stuff at scale, big one right, but only consider it do not use it he's still young a lot of problems uh and a lot of issues there, which is normal because you know we are talking about the project that is infancy, but uh I think it's a project that is very interesting to watch not necessarily to recommend yet but to watch.

A

Absolutely I think you have to reconcile with the rental fleet what they are doing in their repository might be some interest for you. I think you go check that out check out as well. I think the rancher is really a wonderful team because they spun up very good projects like k3s, like I think, and also rancher fleet rancher desktop, is also coming up.

A

There are storage solutions, so I think, because you can expect great things from that team because they are already knowing.

B

A

Presence felt in the industry, so we can expect some good things. Good innovation happening in that space, as well, so before jumping out into the theory where we talk about like in the in your youtube videos you talk about on the first. This is how you should do it just talk about their pros. You talk about how to implement it, and the last part is actually a wonderful comparison, so we will start that comparison later.

A

What the gate of what thing you should not do in the githubs as well so talk about talk is about some cloud scenarios and also the scenarios where kubernetes is not there and people think because it is a really like you are. When you talk about get offs, I think most of the audience is just for the kubernetes, but you always telling people it's not just for kubernetes. You can do things outside kubernetes equally. Well, so talk us about your thoughts on this.

B

So let me start by saying that- uh and this is not most people- do not think this way. So I'm I think that I'm still in minority, but uh I do not see primarily a kubernetes primary function being hey. I can run your applications as containers uh in on some servers right to me. That's not the first thing that I think of today, when I think of kubernetes, I think about api.

B

I think about it being extensible through custom resource definition. I think about uh the ability to detect drifts and reconcile right so uh and then it hit maybe some of the things. It will also run its kubernetes directly like containers, some things it might not right, uh but the important part here is extensibility right.

B

Kubernetes is not supposed to be something that you take and you use that's, not the purpose of kubernetes kubernetes. It's just a set of building blocks that other vendors should use to assemble a platform or you can use to assemble a platform. You take different pieces and you have a platform right now, if you think of kubernetes, not just something that runs your containers, but there's a way to create a platform that has certain capabilities like extensible, api custom, resource definitions, reconciliation so on and so forth.

B

Then I will confidently say that almost everybody will at one moment be using kubernetes, even though not everybody will be running their applications in kubernetes right, which is probably not what most people think about when they sit in kubernetes and the reason I'm saying that is, let's say githubs and I have many other examples we can. We can talk about right.

B

So for me to run github's process, I need to run it in kubernetes simply because all the tools for githubs are designed to run in kubernetes right, but that does not mean that and and uh for github to run uh for that get those process to work. It needs to get those manifests that are defined as kubernetes resources from git and then apply it to cluster, and here comes the important part that manifests that you, starting git, might be describing a database running somewhere else right.

B

It could be rds database in aws, it could be whatever in google. It could be elastic right. So what those tools do is hey. This is what is in it, I'm going to tell kubernetes to apply it and then kubernetes uses something called controllers. That say hey for something called victor I'm inventing. Now uh there is a con associated controller and that controller does something and that something can be. I run a container or I run a database outside of the cluster or I create a cluster or I create a server. It can be.

B

Anything controllers can be literally anything and that's where we are going we're going towards the world in which kubernetes orchestrates everything not only containers running so think of kubernetes. As like uh orchestrator like an orchestra right by you, go there, you go there. You go. Do this, you do that right. It's orchestrator of everything, not only applications, running kubernetes, right and kind of that happens to be the project where I work on work with crossplane, uh but that would be a separate subject. I guess.

A

Yes, absolutely absolutely. We definitely covered that in the future. Episode as well, that's a very good topic to discuss, but I think it's really difficult to understand the what the victory is telling at this moment of time for the beginners like me, but I will accept the all the things that victor said, because his history of telling these stories is actually popping up. So you can see you might see. Githubs are outside kubernetes near future as well, because, as you mentioned to the conversation, there are controllers in kubernetes.

A

Some functionality is missing in kubernetes, but you can implement those functionality in kubernetes using those controllers and these controller. Previously you just build your own one, but now we have tools available for us. They can have some controllers and they can give give you all these kind of flexibilities.

B

Here's a good example for you uh that uh so you used english right.

A

B

What does english do.

A

It is just route the application to like uh you, go there in that part or you go that in that part, it's how I.

B

Look not not really that's what services do.

A

Services so like.

B

Yeah, so so what ingress does I mean? Does few things, but the primary function is to create an external load balancer outside of the cluster, so think about it for a second right. Yes, nothing to do with what is happening in your cluster. I mean it has something to do with your cluster, but very little.

B

What ingress does and kind of people have been using is actually managing resource outside of the cluster or when you create a persistent volume right. What does persistent volume that do in your cluster? Not much the primary function of persistent volume is to get the disk from outside of the cluster and attach it to your containers right, so we already saw for since the very beginning of kubernetes.

B

We saw examples of kubernetes doing things that are not really containers directly related but outside of the cluster who external load balancer. Oh disk, like storage somewhere else, it's just that at the very beginning that was kind of limited to a few things, but now that kind of, like we are kind of all settled into kubernetes, now kind of it's increasing right more more! It's like a black hole right. What's the primary function of black holes to swallow everything inside.

A

Yes, absolutely great way to think about it. I think that's a great explanation for everyone really new to this concept like kubernetes could, as the as is energetic doing some of the stuff that it's not supposed to do, but it's actually doing like csi or storage interfaces. Like you to talk about the network interfaces, then we have a runtime interfaces, so they have some kind of the best practices built in it's up to us to use those best practices and can do like the black hole stuff. Do everything with kubernetes is up to us.

A

If we think about, we can do everything with kubernetes, we can do it and if you think we not do it that's another story, but we can do it a lot all of the stuff that as well so the last question before we go to the pros and cons of the get offs. So people are still deploying some of the stuff in the azure aws gcp they're. All infrastructures are already in there and they're using most part of the aks or ets or gke. That is the most. I think the audience is already there.

A

So how those people, if you tell the story like in the githubs you have the application running in the github or github repositories and your infrastructure might be living in the aks or eks or g key. So for the people who want to use a git ops in the cloud is there are some challenging?

A

What should be awesome? Should they do it or what's the way of thinking about get ops in the cloud like aks eksgk scenarios.

B

No, there is nothing really the only negative thing or complication. Let's say not negative complication is um how to connect githubs for with the processes coming after afterwards right. So uh let's go back to the example. I said about cd right: uh let's I said we built we test and then we deploy and deployment is actually modifying, git repository and then the pipeline is finished uh and uh argo cydia flux will synchronize stuff right now. Let me change that scenario for a bit. Let's say that we build and then deploy and test afterwards right.

B

So our building and testing is happening with pipelines, but deployment in the middle is happening with uh different tools right and and that's all asynchronous, meaning that my pipeline does not know. When argo cd will synchronize it might happen immediately. It might happen a minute later right. So uh how do I bridge that gap? That's the question or a big problem, not problem, but challenge that we have today. If I build something and then I make changes to git- and I don't know when git will, argo cd will do the stuff.

B

How do I know two things? First, when to run tests or whatever I do after deployments, so when do I do that and second, a second question is: how do I do it, because I cannot use the same pipeline build because uh there is a gap. There is a hole in between right and the answer to that which is not yet answered by industry. I believe, but we are getting. There is in uh abandoning the idea of monolithic approach to our processes, including pipelines.

B

So, instead of thinking you know, I don't know, have you used jenkins, for example, or any of okay junkies right uh when we use jenkins- and that applies to all the tools, all the pipelines right or almost all uh the way how we do it is that we define a pipeline. Now you do this now you do that, like build test, deploy blah blah blah blah where we sh will be going, is breaking that into tiny things, actions that are executed as a result of events right.

B

So, instead of thinking in terms, I do this and now I do that and now I do this and stuff like that, uh and we cannot do that with githubs, because it is breaking that conceptually.

B

We need to think about when this happens. I do this and when that happens, I do that and when this happens, I do something else. So let me explain with the example.

B

Let me break that simple pipeline into whenever I push something to get that's an event that results in notifying something to build, let's say container image and then I'm finished right and then some other instead of me continuing with the pipeline, then I have a different process that is monitoring my registry container image registry and saying: oh, whenever somebody pushes something there, I should update my git repository manifest and then it stops. And then you have a third process that says hey whenever somebody updates the manifest.

B

I should synchronize the state githubs, and then you have a fourth process that says hey whenever somebody changes the deployment in a kubernetes cluster, I should run tests so instead of thinking in terms of everything defined as one huge monolithic, blah blah blah blah blah be thinking small, reusable pieces that are triggered depending on what happened, where even all, based on events.

A

Yes, absolutely absolutely.

B

They complicate your picture out too much or something.

A

No, no, it is, it totally makes sense for me, but people might be really new to the gate of these. Terminologies are might be new for them, but luckily we have a youtube channel, that's called devops toolkit and that's built.

B

For that purpose, to make this.

A

Misconception cleared so I will tell you, because this up part is also is for the listener, only mode as well so dev, ops toolkit you should subscribe. I think you will land into the which channel as well. So I think, if, if that's missing, because what you tell, I think, that's really makes sense for me, because argo has all good role: rollouts, rollbacks, argo heads, argo, workflows, argo events, so argus all those things it's up to us to use those things and solve new challenges.

B

I like that, you mentioned the argo rollouts, because I think that that would uh that might better explain the challenge right. So, if you think about the process in terms of I'd a, I do a b c d then uh park that for a second and now, let's talk about country deployments right deployment is not just I put this here.

B

Deployment is a process that says I will send a bit of traffic to the new release majority of traffic to the old release, and then I'm going to monitor how people react and if they like it. If there are no errors, I will increase the reach of the new release gradually and decrease the number of requests going to the old release. Now.

B

The reason why I'm saying all that is that you cannot declaratively decide what you will do after the deployment, because, if you're doing country releases you do not know when it will end, you cannot define in advance when you will do something after that, because you do not know when it will finish right.

B

Yes, and even if you do know when it will finish, you do not know whether it will finish successfully or it will roll back yes, so you cannot decide in advance what you will do and when you will do it, because you do not know when or what will happen.

B

You have just different events that are happening at some moment in the future. Argo rollouts will say finish successfully or at some time in the future. Under future, it will say I rolled back or it will say you know what I'm hanging in the middle of the process, for whatever reason right. So you cannot predict what will happen, but what you can do is to have be prepared to react to different situations, hey whenever argo rollout tells me that he did x.

B

I should do this whenever he tells me, and I will do that by listening to it. This is not important. This is like humans. You do not do stuff randomly right. You listen to what somebody is telling you and then reacting to that something right.

B

You do not know what I will say in advance, but if you listen to what I'm saying, then you can make a decision what to do. Depending on what I said.

A

B

Absolutely and that's how events work. Different processes are all listening for listening to for stuff and then there is a message saying this happened or that happened and then you decide. I will do something or I will do nothing right.

A

Yes, and I think I think that that's a wonderful conversation like you, don't know what actually is happening, but you can prepare yourself for if something happen, you can do this thing that is actually viable for all of the scenarios, and all of that I think the cloud native. If you look at the collaborative landscape, there are some tools or because these analogies act getting a lot of attraction like tool like dapper, k, native or other tools.

A

They are always based on the eventing model, so I think we see a lot of the attraction going on on on this landscape, so we're approaching it closer. We love talking to you, because I don't want to finish these this this conversation, because I love talking to you, but we approaching an hour. So one of the final question before we get the pros and cons is we see a lot of the githubs as a service like we see some of the people tell give you some of the things like this. It's a sas platform.

A

This is get offs. You should use it. Everything is done by yours on on behalf of ours. So how do you look at the github? I will see the code fresh and there are some other people invest, investing time and energy to give you the get ops as a managed service. So what's your thoughts on on that.

B

The question is: what are my thoughts on many services generally speaking, and that includes githubs, I I think I love managed services.

B

I and I think it's important, that we are all moving to many services and the reason is very simple: I I'm having some business whatever the business is I'm having some objectives right and what I want to do in my business is to focus on my business right and I want to use services for everything else now.

B

What that is depends on what your business is right, but if my business is not to run servers, I don't want to run servers myself, because if I do that, then I'm not focusing on what my business is right and the same thing for almost anything else: cicds tools as a service github tools as a service, everything is a service is great because it enables somebody to be focused on providing that service.

B

Well, all everybody else can focus on whatever is their business right. That's why I like cloud. That's like my light services, because it allows me to offload things that I was about to say, do not matter they matter, but they're, not my core business right. You have no business benefit from managing argo cd right, absolutely it's necessary.

B

We need it because it enables some other things that we do but itself it's the same, like it's servers, kind of like nobody earns money, I mean some people do earn money from running servers, but majority of us, our customers, are not paying us to run servers they're, paying us to give them certain service certain, whatever we're giving them. So everything that is not my core business as us.

A

Yes, absolutely absolutely agree with you like: you need to invest a lot of the time and energy, the things you are doing, because that's need some critical stuff, like you're doing scrum calls every day telling about how to set up the github's pipeline. How to do this? How to do that? But you are missing conversation about what the core business you look like and when you have tools available, you should use that, like you can't use kubernetes by yourself, you use aks eks gk.

A

That's probably fine, because in that way you lift off the burden of understanding the kubernetes, and you will unders invest more time and energy. What is running in on top of the kubernetes, because that's important to you and that is actually your domain and you need to invest time on that.

A

I absolutely agree with you on this note as well, and I hope what people are listening to us talk about this and before, as we are also uh the in the hoteliers project, we are investing a lot of the time in the orgo city tooling, or the get off stooling and we have the open source community people are watching watching this podcast or listening to us join us in the hoteliers dot io.

A

You see the discord channel available for us who can hang out and ask them questions and we hope to see some videos on the hotelier side and the victor's channel as well. I I hope victor can look at the repository afterward in the hoteliers, dash, authilius and check what we are thinks things doing in the in the microservices world and tell us about what we think we what we go wrong in there and we need to rectify those things as well.

A

So it's it's up to the victory as well, so go check that out repository as well, so a very good contributor for the different part. We have a very diverse, open source community.

A

We have folks from the or chile, south africa, pakistan, india, australia, new zealand and I think, some from from various other countries, a diverse open source community. As of I know, so I think you should go explore these of the ordinance content as well and before I let you go, we have two or three million more available for us to hang out, and this is up to the victor. Tell us what good and what bad in the kiddos.

B

B

The the major problem with git there is nothing I cannot think of a bad thing, except that it's relatively new, so that many other things in a system are not necessarily prepared for that.

B

Like the pipelines I mentioned before, right, they're, not necessarily prepared for that shift of thinking right, um and so, if there are problems there, that's more lack of tooling um and lack of um support right.

B

We measured country deployments right uh if you use uh flagger or argo rollouts, uh and then both of them are coming from the family of projects that include githubs right, they're, not github stores, but when they roll back they're, not running back in a github-friendly way way right, they just roll back instead of pushing stuff to get and then letting argos in your flags. Do it so and- and that's only uh due to time required for us to adopt the system there. But I think that eventually it's not even about github's.

B

I think it's more about us moving towards even based everything and github's being just very good fit into that.

A

Absolutely absolutely thank you very much victor to being on the show as well. I always learned a lot because I think we have I've done this very episode. Episode previously on my channel cloud native fam today we're doing the beaming otilius podcast, so everybody will watch listening to us. We have a website. You can listen or download the podcast is available. I I hope you checked out as well, and that was one of the very I've talked to 40 plus guests.

A

uh For the for for a year for doing the podcast and talking to victor is always feel I don't want to end the conversation.

A

I want to talk about all day all night days, because because I learned so many new stuff with it and go check that out, if you're not, we are not be friend anymore, because devops toolkit is a wonderful channel 24k subscribers. This tell you. The people are going to this channel and learning about new things from victor farsik. It's been a wonderful way explaining this concept and, if you're listening to us, not watching us so dev, ops, d, e v, o p s t double o l k.

A

I t this is a victor youtube channel and you should join in, and these are all the details that we covered in this podcast. It's all very available as a hands-on material, for you go check that out. It's been a wonderful wonderful show for everyone and we hope to see again victor with. There are some various other topics. Viktor can talk about it, but we can. We hope, to see another episode with the victor as well and also join us.

A

You are enthusiastic about contributing to the open source contributing to the microservices or you wanted to get your hand dirty or you wanted to be a part of the community or are driving effort into that on the microsoft microservices. So italias is one that community. We have a very good folks from the different part of the world and we should explore that github.com.

A

Slash hoteliers, ortillius is our repository and if you want to contribute want to get started with it join the discord server and we will be there to help you on board with the process. So thank you very much victor hope to see you again in the future and hopefully.

B

Hey you're gonna, see me in a month.

A

Yes, absolutely and give god, valencia absolutely absolutely, and everybody who joined, who is going to kubecon, I think you should should should meet victor- is a wonderful human being always talking to you in a very good manner. You always try enjoy the talk with him, thanks victor what spent most time with he was. Your busy person done very hard work for the youtube and also on the job site as well, so hope to see you again in the future. Stay safe, stay, healthy, bye, bye, everyone.