- I say it all the time.
- 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?
- 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 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, 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 is- there 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 mind 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,
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, that, that,
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
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, 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.