Technically Speaking

I say it all the time.

[various clips from previous episodes]

“There's a complexity.” “With all the complexity that we create.” “Automating it with automation.” “The only way we can manage all that is through automation.”

Whether we're talking about containers, edge computing, or network security, when technology creates additional complexity, the only way we tame that complexity is with automation. The nature of automation hasn't fundamentally changed. We tend to automate narrow focused tasks. Yet systems keep getting more complicated. And at each layer we automate, but what can we do to pull it all together?

00:36 — INTRO ANIMATION

Complexity drives our need for automation, but that doesn't mean that automation itself is inherently complex. In fact, when people look at automation for the first time and ask me where to start, I always say that it's important to start with something simple. We don't sit down and automate everything all at once. We break everything down into smaller chunks that are easier to manage. Much like, we started breaking down the large monolithic applications into multiple containers and services. Automation has evolved from simple scripted tasks to large-scale collections and orchestration. Ops teams and Sysadmins automate config management, think configuration-as-code, and create immutable infrastructure, think infrastructure-as-code. Developers speed up builds and software delivery processes these with CI/CD pipelines. We can infuse security policy and compliance with policy engines and zero trust. And when we look at doing all of these things at scale, when we need more devices, more containers at the edge with automation like zero touch provisioning, all of this falls under the umbrella of everything-as-code. Everything-as-code is the practice of treating all parts of the system as code. With code we can describe the series of steps to take or declaratively state the result we want and store that configuration along with our source code in a repository, such as Git. Everything-as-code introduces a world where our infrastructures, workflows and services start to demonstrate programmatic patterns. And once we have defined patterns, we're able to build and trigger automation, essentially everything-as-code is automation. DevOps had configuration-as-code, add infrastructure-as-code and everything-as-code using Git, this is what we could call Gitops and to get into the topic of Gitops. I'm excited to talk today to Stefan Prodan. Hey Stefan, how are you doing?

Hi, Chris, it's great to be here.

Well, thanks for joining to talk about this, this notion of Gitops. And like to me at its core, Gitops is an operating model for Kubernetes and, and other cloud native technologies. I think the way I think about it is, you know, the, the, everything as code, you've got whatever you're working on, infrastructure, configuration, even policy for compliance. You put that into your Git repository, kind of creates a trigger of actions that flow after that. How do you think of Gitops? How would you define it?

Yeah, I would say Gitops, is more close to the idea of infrastructure as data where, let's say users that want to define how a production system works from infrastructure items, to deploying applications, to configuring security policy for those applications to configuring how that application is exposed outside the cluster, all these things can be expressed as you know, Kubernetes objects. That's a great example. And Kubernetes object placed in a Git repo is a YAML file and I am thinking about YAML files as pure data. Right? So the idea of Gitops is that you have this system where you can treat your configuration as something that's static that is versioned, that you can collaborate on. And the second aspect isthere is something running in your production system, on your clusters, that are monitoring those Git repositories and are considering those repositories as the desired state of the whole system. So there is a mild shift here: instead of you going from your repo to the cluster, the cluster pulls the repo inside and reconciles its own state. Here it's also about it's, it's also a security improvement, so to say, your CI system no longer has to have all the secrets to connect your production system. The system connects to your desired state being a Git repo, I don't, maybe an S3 bucket or a Helm repository and so on.

That's a great contrast of a push versus pull model. There's clear scalability benefits, and as you even described, there can be security benefits. And I like how you brought in that it's not necessarily code– it's data. And that really plays to the strengths of Kubernetes. And we talk about it using a declarative language to establish desired state that's, that's a data description of your infrastructure, your application needs. And then having that flow through the system pulled and reconciled in the, in a Kubernetes native way, which is looking at the difference, the drift between desire to save a current state, that's a deep integration to CI/CD pipelines. There's, gotta be tools in there that, I know you're working on that are important in this picture. What are some of the tools that you see as, as really critical valuable tools in this sort of Gitops CI/CD world?

I'm a maintainer of two Linux foundation projects, which are under CNCF. One, one tool is called Flux. It's a collection of Kubernetes controllers that allow you to define these continuous delivery pipeline in a Gitops way. And the second tool is called Flagger, which allows you to do a progressive delivery of your apps when it comes to deploying in production. But there are many other tools that are, they're in CNCF, for CDF or other foundations, open-source tools that, you know, allow you to apply Gitops practices.

It's important to see that kind of transition from Gitops as just a label and a concept to it's really taking off. And we see all the projects and proliferation of, of, of users. And I think that means we've turned it into something that's a reality. Now what about Gitops beyond Kubernetes? There's, there's lots of things outside Kubernetes, creating databases, or, you know, different cluster infrastructure beyond our control of our Kubernetes to different ways that we're doing application and code delivery. I feel like there's, there's a lot that Gitops can provide. How do you see that?

Yeah, Gitops is based on Kubernetes and Kubernetes has opened a better way of declarative configuration and declarative operations. So let's say you can extend the Gitops model with other specialized controllers, right? In the Kubernetes world, these are called custom resource controllers. So you can create a custom resource that defines something outside Kubernetes, like an S3 bucket or an RDS database. And so many other things. The principle is the same. You've declared this object in your Git repo. You have Gitops controller that reconciles them, and you have a specialized controller that takes action based on those definitions. And they can create the bucket or the database and they can modify it and so on.

This has been great, Stefan. I can really see how Gitops takes Kubernetes core capabilities, gives the tools we need to deliver to these complex environments and can even expand beyond Kubernetes in envisioning how we do a broader management of these really complex systems that are the infrastructure of today's applications. We've got a toolset, we've got triggers for push and pull. We got this data– single source of truth, and I can even envision ways in which there's a broader set of data that's informing system's behavior that we can incorporate into that Gitops mindset to really give us the next generation of management tools and automation for cloud native applications. I really appreciate your time. Thank you, Stefan.

Thank you very much, Chris.

With Kubernetes orchestration, we have the benefits of containers that make it easy to scale up deployments in management. Gitops gives us an automated process for continuous deployment that can help us manage the growing complexity of everything at scale. With infrastructure-as-code, continuous compliance and event streams, we can then begin to train and apply machine learning and intelligence-driven automation, which will help us reap the rewards of this complexity.

09:43 — OUTRO ANIMATION