BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Alex Matyushentsev on Argo CD, Argo Rollouts, and Continuous Delivery with Kubernetes

Alex Matyushentsev on Argo CD, Argo Rollouts, and Continuous Delivery with Kubernetes

Bookmarks

In this podcast Alexander Matyushentsev, principle software engineer at Intuit and core engineer on the Argo CD and Argo Rollouts projects, sat down with InfoQ podcast host Daniel Bryant and discussed the Argo projects, continuous delivery with Kubernetes, and how platform teams can help developers embrace modern release techniques and related technologies.

 

Key Takeaways

  • Argo CD is a continuous delivery tool for Kubernetes, which uses declarative configuration (Custom Resource Definitions) and a GitOps approach. Argo CD automates the deployment of the desired application states in the specified target environments. 
  • Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
  • Both projects aim to make it easier for developers to deploy and release applications on Kubernetes. This supports the initial stages of the “you build it, you run it” approach that is becoming increasingly common within cloud native organizations.
  • A series of web-based UIs make it easier for developers to visualize and understand deployment progress and related issues. And many of the tasks that are typically accomplished via the Kubernetes CLI can be automated or triggered via a web-based UI.
  • The Intuit platform team is a core contributor to the Argo projects and makes heavy use of these tools internally. The platform teams also provide developer training and share best practices for deploying, releasing, and operating applications.

 

Transcript

Daniel Bryant: Hello, and welcome to InfoQ podcast. I'm Daniel Bryant Director of DevRel at Ambassador Labs and one of the co-hosts at the InfoQ podcast. Today, I have the pleasure of sitting down with Alex Matyushentsev a Principal Software Engineer at Intuit, and we explore topics such as continuous delivery with Kubernetes, the practice of GitOps, and the Argo projects. 

Although continuous delivery is not a new practice, several new approaches to this in the cloud and Kubernetes ecosystems have emerged. One being GitOps where infrastructure and app conflict state is defined in version control and automatically synchronized with the target cluster, simply speaking. Extending some of the ideas around CD is the concept of progressive delivery, which focuses more on releasing strategies, seeking to maximize feedback, and minimize any blast radius if things do go wrong. Here, we have topics such as blue-green deployments and Canary releasing. 

The Argo family of projects are a series of CNCF open-source tools that enable continuous delivery, GitOps, and progressive delivery on Kubernetes. The target users are developers and the projects aim to simplify the Kubernetes developer experience and the corresponding workflows.

Alex is a core maintainer of the two Argo projects, Argo CD, and Argo Rollouts. And I've learned a lot from reading his blogs over the past several years. I was keen to chat with him and understand the motivations for creating the tools, the current state of the projects, and where he sees the community taking these tools in the near future. 

Introductions [01:32]

Daniel Bryant: Hello, Alex, and welcome to the InfoQ podcast. Could you introduce yourself to the listeners, please?

Alex Matyushentsev: Yes, sure. Hi everyone. So, my name is Alexandra Matyushentsev. Don't try to pronounce my last name, I usually prefer to go just by Alex M. So, I'm a principal software engineer. I work for Intuit and I'm a maintainer of Argo project. And basically, Argo is not just one project there are four, and I used to work pretty much on each and everyone, I guess. But, my primary focus right now is Argo CD, the continuous deployment tool for Kubernetes, which follows GitOps analytic.

Could you provide a high-level overview of the problem space and the motivations for why the Argo suite of projects was created, please? [02:07]

Daniel Bryant: Brilliant. So, as you mentioned there we're definitely keen to dive into the Argo ecosystem today, particularly Argo CD and Rollouts and we can definitely focus on CD a bit more. Before we do, could you provide a high-level overview of the problem space and perhaps the motivations for why the projects were created?

Alex Matyushentsev: Yes, sure. I guess it's pretty much true about every Argo project. So, our team recognize that Kubernetes is an awesome platform, but it's so generic so that it's not really trying to solve any particular use case. And that's why it's extremely powerful. But at the same time, the end-user experience is not really the best because you have so much choices how you can do things. And Argo are trying to just solve the most common use cases in an opinionated way but it tries to make user experience as best as possible. And typically by end-user I mean developers because we believe that developers supposed to interact with Kubernetes and use it. And so that, we're trying to create tools that make development life easy as possible.

Daniel Bryant: Argo projects, they're open source, they're CNCF, as I understand it. And unlike say other projects, there's no commercial entity behind it because you work for Intuit. I see a lot of BlackRock folks working on it as well. There's no one company that controls Argo.

Alex Matyushentsev: Yes, that's true. So, Argo was born in a small startup company, which was acquired by Intuit. And since then, basically, I don't think there is any commercial entity, not like Intuit, definitely not trying and not going to try to sell it. And that's why project was donated to CNCF. And I think it's fair to say that CNCF controlled the project. And there are several end-user companies, like BlackRock and Intuit, maintain and contribute to Argo as well as there are several vendor companies like Red Hat and Codefresh. And they'll also be part of the community.

Daniel Bryant: Ah, brilliant. Brilliant. Yes. I always like to understand where the communities come from and where it's going. I think the CNCF is doing a fantastic job, right. There's plenty of choice in the CNCF ecosystem.

Alex Matyushentsev: Yes. I feel having both types of companies brings a lot of value. En-user companies can contribute a lot of knowledge because basically, end-user companies have users right next to developers who develop the project. We learn about real problems from real users, but at the same time end-user company is not making money on the project and that's why you need new help and we're really grateful. When I had joined the project it really changed the pace and our project is doing, I feel, way better. We have more people looking at issues and answering questions so that helps a little.

What functionality does Argo CD provide? [04:36]

Daniel Bryant: That's awesome. That is awesome. So, diving into the projects, individually now, when we look at say Argo CD, what's the role of that project in comparison, perhaps, with all the other Argo projects too?

Alex Matyushentsev: Basically, the project was created at Intuit and we were trying to solve an upcoming pain. We were trying to onboard potentially several thousands of developers onto Kubernetes. And we knew that these developers has almost no Kubernetes knowledge. And basically, that set a lot of limits to... Basically, we needed a tool that end users don't have to install because you cannot ask someone who has no Kubernetes knowledge to install something into Kubernetes to manage Kubernetes, it would be too much. And basically, we were just trying to build effective user-based application that helps developers to manage Kubernetes. Actually, there was no goal to build anything. We just supposed to get something. And we looked at existing set of solutions. We looked at Spinnaker, we looked at Flux. And then we really like the model of Flux. We understood this GitOps concept and it was really compelling to us.

Alex Matyushentsev: We didn't want to reinvent, I don't know, our DT solution, Git would solve it for us. And GitOps we like it, at the same time we didn't like that end user's supposed to install and manage Flux. So, we sat with the idea. And then we look at Spinnaker, which is completely opposite solution. It's very heavy and it's provided as service. And we tried to merge this into one project and this is how our procedure was created. And I think we did this. So basically the idea that Argo CD provides you GitOps functions as a service and it has web user interface, which is very important because it's maybe the most friendly way to end-users to expose these features.

Daniel Bryant: Yes. And I've been using Argo CD for a number of months now, a year, probably more. And the UI is fantastic just for understanding what's going on. Particularly when you're changing things in a cluster the UI is really useful.

Alex Matyushentsev: Yeah. The UI is totally influenced by a number of questions in support channel. Every time we're noticing the same question is asked again and again, it eventually made it into a feature in the user interface. You cannot imagine how many times we've got a question that, "How come my reports are not starting?" And that's why we had to create this red pages that are visible on the UI. And every time if user click on report, you will see at the top, which is events stuff, that show Kubernetes events. And it has this popping creates a page. It's asking user, "Click me." And if user click on that stuff there will be an answer for it. So every time UI is changed, it's to simplify life of support people, of a platform.

How does Argo CD make is easier for developers to adopt GitOps? [07:13]

Daniel Bryant: I like that a lot. I like it a lot because just for the recap for the listeners. So, the GitOps principles is we declare our configuration and store it in Git, and then something like Argo CD synchronizes that with a target cluster. So, I could do Kube-cuttle, apply using a command-line tool, and apply. And then if I wanted to understand what was going on in my pods I could do Kube-cuttle, describe et cetera, et cetera. But Argo CD not only does the synchronization part and I don't need to do Kube-cuttle apply. But to your point, it makes it easier to understand and look around the cluster visually.

Alex Matyushentsev: Yeah, that's right. And I think maybe we were supposed to sit and take and explain what GitOps is. I assumed people know, but it's fair, it's not really... GitOps is this old idea about starting things in Git and use it as a sort of tool. I don't think it's extremely new it's been there for decades, at least. I think a lot of pre-Kubernetes tools were effectively doing GitOps, but I think Kubernetes made it so simple. Basically, you have all the tools to do GitOps built-in into Kubernetes. And I'm pretty sure Argo is just trying to build on top of that. And it's trying to improve user experience as well as any other tool on top of Kubernetes. And we have project managers, they hate when I give that description, but we internally view Argo CD every Argo project as some glorified feature of Kubernetes. Basically, Argo CD is a glorified Kube CTL applied.

Daniel Bryant: Nice.

Alex Matyushentsev: It just “kubectl diff”, “kubectl apply” packaged into web application.

Daniel Bryant: I've never thought about that. That is actually a very marketing-friendly pitch there. I think I like it a lot.

Alex Matyushentsev: It's totally not friendly. Basically, it makes the description of tools sounds like it's not very important. But basically, it explains very well what it's doing and we have similar description for every Argo project. So, Argo Workflow is a glorified Kubernetes job and allow this glorified deployment. So yeah, we pretty much, we just identify its use case, which is not solved extremely well on Kubernetes and then just build on top of them, and try to have that opinionated implementation.

How does Argo Rollouts compliment Argo CD? [09:14]

Daniel Bryant: How does Argo Rollouts compliment Argo CD?

Alex Matyushentsev: So, Rollout was created after Algo CD was created and adopted at Intuit. And we realized that GitOps is not really friendly to complex deployment processes. It trends if you just need to run QCCL apply and that's it, and then Kubernetes take over and finish the deployment for you. But, what if you have a sequence of steps? And we did several of them. So, we tried to just commit many changes into Git, deployment would look like you commit stage number one into Git, and then wait for the same process to be in sync. Basically, wait for Algo CD to sync the changes and then step two insert CD. And as you can imagine no one like that. The next attempt was to just try to have one stage stays in Git, but maybe use some scripting. And we try to just script this process in Jenkins.

 

And it was not perfect either because you would have to give Jenkins pipeline access to Kubernetes or whatever CI tool you're using. So it was not perfect either. And then it was clear it's really hard to do it in Jenkins because the deployment process could take days. What if your intent is to have a Canary that runs for one day and then you take measurements and so on and so forth. So, it was clear it's not the best choice.

And finally, we realized that maybe that logic should not be living outside of the cluster. Maybe you want to put it into the cluster. And so we try to compare how is normal, any deployment different from built-in rollout deployment? And it was almost the same, except you just need a few more configuration in Ops. And basically, that inspired us to create a customary source, which is almost like deployment, but it has few more features, more complex deployment strategy. You can pause it and resume. And so that's why I think the best way to describe Rollout, it's just a replacement of deployment resource in Kubernetes. And that they got the exact same set of features plus additional deployments.

How can Argo Rollouts help with canary releasing? [11:14]

Daniel Bryant: Makes it nice and easy to do, say blue-green deployments, Canary. You can say, step one is 20% of traffic, pause for a certain period of time. You can also, more advanced use cases, do things like analysis, I believe as well, where you can perhaps call out to a metrics or an observability system and say, "Is the error rate within this threshold?"

Alex Matyushentsev: Yeah, that's right. So, Argo Rollout has set the implementation of some most complex use cases again. So as you said, typically, if you do Canary deployment, you want to grab some metrics and compare before deployment and after deployment metrics and make some decision and proceed. And so instead of asking each and every user to write a basket to do it, Argo Rollout gives you first-class support for various metrics providers like Prometheus, some use Datadog and you can just write some expression that's specific to that provider. And you can, for example, compare error rate before and after deployment. And in addition to that we had to build some support for again, the more use cases. So for example, if you use a tool reviewed and built to the Kayenta it's built for Java applications.

And the reason is in the world of Java, when you're comparing previous a new version of code, you're supposed to start a fresh instance of your application. Because if your Java application run for a month, it will give you a very different set of metrics in the application that you started just now, even if it uses the same code. And so for the other credential users who needed Kayenta. And that's why we had to build things like Experiment in our world. So, Experiment lets you basically start a fresh copy of an application, and you free to choose which version of your application you want to use and your choices previous, or let's say stable in the new one. So, you can run them side by side, collect metrics and make decision. And that's just one example of such features. So, basically Argo Rollout, I think a dozen have such well-known cases that you want to use if you do produce the delivery.

Daniel Bryant: That's super interesting, Alex. I hadn't actually thought that deep level. Because I've played around with the analysis in Argo Rollouts and it's super interesting and that we can specify thresholds and we can look at all the classic golden signals, right, in terms of latency and errors or these things. But, you've just made me think the Java, for example, you gave there running an experiment because Java relies on Git compilation. So, if it's been running a long time, it's going to be optimized to the use case. But obviously, if you want to do a fair comparison with an improved version of the app, you want them both starting the same time. So, Argo Rollout opens up that use case.

Alex Matyushentsev: Yes. And I feel basically, maybe that's the reason why this feature is unlikely ever going to make it into Kubernetes because they're so opinionated. I think to accept it into such big project as Kubernetes it will take several years of validation and we were free to edit into Argo CD. Maybe one day, these features of Argo Rollout could eventually be part of Kubernetes deployment.

Both Argo CD and Rollouts make use of Kubernetes Custom Resources Definitions (CRDs). Could you explain what the Argo CD “Application” custom resource is for? [14:08]

Daniel Bryant: So, we mentioned Argo Rollout there, and there's a custom resource called Rollouts that replaces deployment. With Argo CD, I believe there's an application custom resource. That's the main template for defining how we would think about an application within Argo CD.

Alex Matyushentsev: It didn't have to be a custom resource. Application is just a configuration of Argo CD that explains which set of resources you want to manage. And it points to a Git repository that has your intention. Basically, when you create an application, you're supposed to say, here's my Git depo and some folder in the depo and it has set of resources. I want Argo CD to inject this resources into a certain namespace in some Kubernetes cluster, that's it. And we chose to use CRG to store that setting simply because we want to make Argo CD as lightweight as possible. So, our choices were to bring our own database or just use Kubernetes. And because Argo CD is for managing Kubernetes, you can safely assume user already has a Kubernetes cluster so it was obvious choice. We just chose to use CRG as a database.

Alex Matyushentsev: And it brings some additional benefits. Basically, Argo CD can manage itself. We do it like introduction. Basically, we have Argo CD that has a Argo CD application, that application points to a set of manifests that has Argo CDs deployments as well as set of applications. And then you can make a change and Git creates one more application, for example, Argo CD will notice it and it will apply that configuration and change its own set of settings.

Daniel Bryant: Very cool. It's almost like an inception-type moment there, right? Argo CD controlling Argo CD.

Alex Matyushentsev: That's right. And it works very well. If you ever visit Argo CD meet the people, you will notice there is a link to a public Argo CD instance that we use for demo and for testing. And this is that example of such Argo's. So, it's Argo that's continuously redeploying itself from the term tip of master of a public GitHub repo.

How does Argo Rollout integrate with Ingress or a Service Mesh? Does the project make use of the standard Kubernetes resource model? [16:06]

Daniel Bryant: That's very cool. That is very cool. So, I'm thinking broader picture, now. I really like your take on simplifying certain workflows within Kubernetes. So, you mentioned you can make the assumption that everyone's got Kubernetes running. I'm thinking for things like Argo Rollouts, you're going to be making some assumptions around, say ingress or service to service communication. I wonder if you could talk a little bit more about that as in, I guess Argo Rollouts has to integrate into various API gateways, ingresses, and maybe service meshes too?

Alex Matyushentsev: That's true. Yes. Argo Rollout started with a very simple use case that didn't require integration with any service mesh it was blue-green deployment. And in case of blue-green, in the beginning, it was enough to simply interact with built-in Kubernetes services. And then later on when we introduced Canary, basically in case of Canary, you want to do fine-grain traffic management and basically, services and not longer enough. And that's why, yes, Argo integrates with various service mesh implementations. It supports SMI. So SMI, as you might know, it's an interface available in Kubernetes and you can install different implementations that supports SMI, but it's not enough. And basically, Argo has first-class support of most popular meshes, like Issuer and LinkaG and others. This is tentative revision, not so much other.

But, I think it's really, not a dozen, but at least it's more than four, I think more than four integrations. And what Argo Rollout does basically in it Argo Rollout strategy you can configure how much you want your Canary deployment to serve and how much traffic should go to stable. And Argo Rollout will try to modify whatever objects control your service mesh. It will try to make a intention to basically. So, if your users still go and check, we will have to provide link to a virtual service and a lot will go into modifications in a virtual service subject.

Daniel Bryant: Interesting. So, I could definitely see the vision of Argo CD and Argo Rollouts providing that layer of simplification or more correctly, I guess the correct abstraction for developers. Because a lot of Kubernetes stuff I think has been built with operators in mind, platform people, sysadmins. And what I'm hearing from yourself is a lot of the effort I think around Argo CD and Rollout, say, is defining the correct abstractions and then mapping that declared state in the abstraction, into the actual mechanics of Kubernetes and service meshes, things like that. Would that be fair?

Alex Matyushentsev: I think it's fair. Yes. And then I feel it's fair about almost every Kubernetes project that's... Kubernetes provided that model and we are now just trying to use it, and implement it.

In your experience, are developers happy working with Kubernetes custom resources with YAML? [18:42]

Daniel Bryant: Yeah. Yeah. I like it. I like it. And what's your experience? Are developers happy working with Kubernetes custom resources with YAML? Because I mean, back in my day I was doing a lot of XML work, right, in Java, and I hated XML. And now I hate YAML. I'm curious. Do you think developers are happy with dealing with these slightly more operational concepts?

Alex Matyushentsev: I think it basically depends on what you compare it to. I know that a lot of users are really happy because developers who wants to have more control and they want to maybe do rapid experimentation, they extremely happy about Kubernetes. But, you also have different developers. If you have a company and every team is building a small micro-service, which doesn't have so much of complex infrastructure. And for these developers, basically, you do not want to have 100 experts in your company. It's enough to have a few. And so for these developers, maybe Kubernetes is not the perfect state. And they're basically looking for more Heroku-like experience where you have less control, I can understand it. But, I would not call these developers unhappy they really reap the benefits that Kubernetes provides.

Do you think that we will get to Heroku-like experience for Kubernetes in the near future? [19:49]

Daniel Bryant: Yeah. What do you think in the future, Alex, do you think that we will get to Heroku-like experience for Kubernetes?

Alex Matyushentsev: I see that a lot of things happening in the community, like Alibaba and Microsoft, they driving open application model and I think that's very promising. And basically, something like that is needed, but it's a slippery slope. And basically, so far I see, I saw it two directions. One is to try to abstract Kubernetes away and expose something less complex. But, because it's less complex, it's less flexible. And so that basically transitioned from, sooner or later applications outgrow this simplified model and they want more controls. And then they have to go through painful migration and migrate back to deployments and services. So, I'm hoping that one day project will be created that implements a nice compromise between two. You can work with hell of an obstruction, but at the same time, you still have access to complex configurations of Kubernetes as needed. But, I don't think that project exists already. So, maybe it will be one more project of Argo, who knows?

Daniel Bryant: You heard it here first. Brilliant, brilliant. It's always tricky. Something I took away with my programming career is this notion of mechanical sympathy, right. Even if I could try I couldn't build a processor. I knew about time-slicing. I knew fundamental things. If I wrote my code a certain way, I would get better performance. And I think there's a danger there sometimes, right, if we try and hide Kubernetes or certain things from developers, they may not write the best applications. I'll be curious to get your thoughts on that because distributed systems are hard, right?

Alex Matyushentsev: Yes. I think you're totally right. Yes. If you hide the features of Kubernetes from developers, maybe you will make people who don't need any of these complex features, maybe you will make these people happier. But, others who really need these features, basically they would view your platform as it's standing in their way. And we internally at Intuit, we have a lot of such users as well. We have our users who just enjoying having access, to be able to create services and deployments. And I saw very complex applications that Argo CD user interface provides you this visualization and typically the hierarchy of resources won't even fit into a big 24 inch screen.

Daniel Bryant: Wow.

Alex Matyushentsev: So, applications are quite big and complex.

When you are working in a big organization there's clearly going to be a range of skills and a range of requirements for CI and CD? What’s your experience like at Intuit? [22:09]

Daniel Bryant: Yeah. When you get to a big organization there's clearly going to be a range of skills and a range of requirements isn't there, and catering to all of them is really hard.

Alex Matyushentsev: Yes, I agree. But at the same time, I feel like Intuit is going for the journey. Our first bit was that we expected that every engineer eventually going to run Kubernetes, at least we didn't expect everyone to learn how to run Kubernetes, but we expected everyone to understand how to use Kubernetes. And I felt very confident in that idea, after several years, I'm no longer that confident. And the reason is, unfortunately, I mean fortunately or unfortunately, they just keep evolving and basically, it's impossible to learn it, but you have to keep learning new things all the time. New things get introduced and that possesses a problem. Eventually, developers get tired of it. And what we ended up doing is we have a whole team that, what they do, they build tools that scan definitions of manifests in all the reports in the company and look for things that maybe wrong or maybe have to be improved. And then they sent a set of automated pool requests that's trying to improve things.

Daniel Bryant: Oh, awesome.

Alex Matyushentsev: So, it's not perfect. Basically, we now understand that some obstruction is needed, and I guess that eventually will be the next step, at least at Intuit to try to abstract a way or provide some least painful way to abstract a way a little bit of Kubernetes and bring some automation to manage Kubernetes clusters.

Do the platform teams at Intuit provide training and teaching, or are developers expected to learn Kubernetes on their own? [23:36]

Daniel Bryant: I like that, Alex. I like that. Yeah. That's very interesting. Out of curiosity, do the platform teams provide training and teaching or are developers expected to learn Kubernetes on their own?

Alex Matyushentsev: We have a whole team that provide teaching and basically leads of every division of platform team usually drive this. So for example, I have to give repeatedly talks about Algo CD and someone else talk about Workflows and Rollouts internally. And even that is not enough. We also have so-called Def buttons, basically, a set of Git depositors that collects the most, not obvious things, the most well-known things. You don't have to manage Kubernetes deployments, Kubernetes resources just using plain YAML there are a set of tools like Helm, Customize and so internally we chose customize.

And we provide a set of customized remote basis, basically, just a bunch of folders stored in Git. And we encourage developers to use one of these instead of starting from scratch every time. So, what we do with basically every time we see that, oh, we know that in the new version of Kubernetes, now deployment's supposed to have readiness gates for example. And so we can put the readiness gates into the remote customers base. And then we will just ask developers to upgrade to a new version, just bump the Git tag in reference to that and get remote customer base.

How do developers track (and approve) changes that ops want to make to configuration? [24:54]

Daniel Bryant: Oh, that's super interesting, Alex. So, you've got almost a template system. So, you say here's a template, copy this, group from this, and put it into your own. But not only that you've got a way to keep that template up to date.

Alex Matyushentsev: Exactly. Yeah. It gives us the opportunity to improve it over time and Git helps us to deliver it safely. So, developer can increment the version and then just use Algo CD to visualize the difference.

Daniel Bryant: Oh, nice.

Alex Matyushentsev: And at least get the glance and understand what is going to be changed, and then just click sync button.

Daniel Bryant: Oh, that's brilliant. Yeah. And I'm getting the picture now because when I'm teaching Argo CD I always show the diff you know, declared state or desired state, and what's actually in the cluster. And that's a great way to understand there's a security update to the deployment stanza or user new conflict goes in. But developers, they don't have to worry too much about understanding the YAML details or what the command line. They just can look at it in our Argo CD and just understand the differences. And with support from the platform team saying, "This is the reason why we've done these things." It's an easy choice for the developers to make.

Alex Matyushentsev: Exactly, yes. These automated PRs they obviously have explanation and platform team would make sure that there explains that this change is required because of that and that reason. And then developers, they know that change came from platform team so they can trust us and there's an explanation. And let's say they also learn that new things was created and that happens in Kubernetes in this way. At the moment when they have to upgrade, they also have to at least a little bit understand about the change that happened.

Daniel Bryant: Yeah. Fantastic. I think that comes nicely back to the conversation we had around mechanical sympathy as a developer, just understanding enough about Kubernetes so that you can say, "Yeah, that change looks good."

Alex Matyushentsev: Exactly.

What's the roadmap for Argo CD and Argo Rollouts? What is exciting for you in the world of Argo? [26:38]

Daniel Bryant: Very cool. That's very cool. Well, I know we're coming close to time here, conscious of that. I'd love to get the quick overview of where do you see the Argo projects going? What's the roadmap, what's exciting for you in the world of Argo?

Alex Matyushentsev: Yeah. So, I think Argo got so big so that it's hard to speak about the whole Argo. And so we have to speak about each and every project independently. I know that Argo CD is not even close to fisher complete. We have still a lot of plans going forward. So, one of the choices we've made when we started Argo, we decided that each and every project is going to be focused on one use case. So, we do not want to bloat them a lot. And that's why Argo CD is going to be focused on continuous deployment use case using Git as a source of tool. But, we also realize that a lot of things you want to do with Argo CD, for example, things like notifications, things like integration with Git, and basically we're working more actively now on creating so-called ecosystem projects. So, in addition to Argo approach, we have a different GitHub org called Argo Labs, and that's a collection of each project.

Alex Matyushentsev: And every project in GitHub.com Argo approach labs, every such project, you can expect a good quality. Basically, it's also maintained by community and maintainers and you will see more of such projects in that GitHub organization. And Argo CD also has a lot of plans. We still trying to make a lot of changes in the Algo CD core. So, we've wanted to not transform it into Kubernetes Dashboard, but basically introduce more Kubernetes ecosystem getting more and more customer resources. And Argo CD started from providing you just base visualization. Basically, you can see the YAML definition of a customer resource, you can see maybe well-known fields of that resource, but apparently, it's not enough.

Alex Matyushentsev: And now in the upcoming release, we want to bring custom visualization for customer sources starting from rollout. And you might see it pretty much, very soon. So, idea that you might not know it, but basically Rollout has its own dashboard.

Daniel Bryant: Yeah, I've seen it.

Alex Matyushentsev: And you can write the dashboard as a standalone component on your laptop. And we just want to bring the exact same UI into Argo CD UI.

Daniel Bryant: Ah, nice.

Alex Matyushentsev: So, that you can click on allowed resource and you would see a visualization specific to Rollout. We were forced to do it because Intuit heavily uses both CDN or allowed. So benefit, it's obvious. But, we're building in a way so every other Kubernetes resource can eventually be visualized in Argo CD.

Daniel Bryant: That's interesting.

Alex Matyushentsev: I know that Argo CD users are going to be happy to see it. And another set of investments we are working on is... So, right now Argo CD has first-class support for custom config management tools like Helm and customize. And at the same time, I think we have a dozen open feature requests to introduce first-class support for Tanka. Basically, there are a lot of other config management tools and it's a fair choice for us. It's hard for us to provide good support for all possible, I think, management tools. And so instead we decided to build a mechanism that will allow provided support through customization, basically. We already have a full mind support for config management plugins, but it's not as good as first-class support or for, I think, management tools. And we want to improve it and make the end-user experience as good as first-class support. Hopefully, that makes sense. There are two very big things that we are going to work on in Argo CD, I guess in the next quarter.

I thought Argo CD was almost feature-complete, but the community plans to continue to add functionality? [30:06]

Daniel Bryant: That's super exciting, Alex. I'll be honest, for me, Argo CD is very complete. And until talking to you, I wouldn't have thought there'd be lots of other things needed to be doing. So, that's great to hear that the project is super active and you're constantly improving is fantastic.

Alex Matyushentsev: I feel like it's good and bad. We have several directions that we can go. What I mentioned is... Both features that I mentioned it's about this typical big company use case where you have a lot of users and a platform team that is taking care of these users, and you want to make life of these users as easy as possible. And so we need to provide this UI features and support more backend management tools. It's all great. But at the same time, we have a completely different set of users who are asking for simplicity.

Daniel Bryant: Yeah.

Alex Matyushentsev: Keep saying, "Oh, let's not worry about that. Can you make experience easier?" Like, let's say, if you are a small team and you're all admins of your cluster and you want to just manage your cluster. And if you go ahead and try to install Argo CD, you have to immediately start to worry about built-in Argo CD users, and so on. And for these people, it's like, "What the hell? Why do I have to worry about it?" So, we're trying to improve this as well. So, in the app planning to that one release, we are introducing Argo CD Headless Mode. Sorry for that name but it's the best we come out with. But, idea that it's a new way to install Argo CD. And once you install it in a Headless Mode, basically you don't have to worry about access control because Argo CD longer will be available outside of a cluster. Basically, there is no UI, no API, but you still can get user interface locally through Argo CDs life. Basically, it would just use port-forwarding to connect to the natures cluster directly and UI will be running correctly.

So, there are a lot of different directions the project is going on right now, simultaneously.

Daniel Bryant: Yeah, it sounds like it. Yeah.

Alex Matyushentsev: t's hard to say what is the most prominent feature on the roadmap? I feel like there's a lot of equally great features coming in, usually.

Many thanks for sharing your knowledge! How can folks get in touch with you? [32:46]

Daniel Bryant: That's super exciting, Alex. Super exciting to hear. Yeah. Great stuff. If folks want to follow along for the project or follow along for your work, what's the best way? Follow the folks on Twitter on LinkedIn, what's the best thing?

Alex Matyushentsev: Yes. I believe Twitter and our medium blog. Yes. We are very active on Twitter, we trying to publish news that we see in the community. A lot of end-users, they publish blogs about how they use Argo and we typically reiterate it in Argo Twitter and we use Argo medium blog. So, it's blog.argopost.io. We use blogs as a way to talk to our users and explain what new features are coming. And this is our way to broadcast the changes. And if you want to talk to us directly, please join @cinthiaflack and we have channels for Argo CD, or close Rollouts, and even set of more specific channels, we already have some channels per feature. So, example, is Algo CD there is, I would not call it... Okay, per ecosystem project. So, one of the projects I really like there is a project called Argo CD autopilot. So, it's a CLI tool. In a positive, it's Kubernetes manifest in a meaningful way. So, it will scale when you get into production and a active channel where people discuss this particular ecosystem project.

Daniel Bryant: Perfect. It sounds like the Kubernetes slack is a good place. I'm often there myself. The community's fantastic there, right. So, I think if folks want to get involved, go onto the slack channel, have a look through the various Argo channels, and reach out there. Yeah.

Alex Matyushentsev: Yes. That's fair.

Daniel Bryant: Perfect. Well, thank you very much for your time today, Alex. It's really been fun.

Alex Matyushentsev: Thank you.

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT