By Richard Lander, CTO | April 26, 2024
As the term suggests, GitOps is a method for using configurations stored in git repositories as a source of truth for software operations. It is a type of continuous delivery for cloud native systems that has grown in popularity as Kubernetes has become more prevalent.
Continuous delivery is the practice of using a set of configs to define software delivery. Compared with simpler manual systems, it improves the velocity with which you can deliver software, and update it, in its runtime environment. This allows you to iterate faster in development and deliver features and bug fixes more rapidly to your end users. For more information on the topic, see our blog post, What is CI/CD?.
Now that Kubernetes has become the industry standard for container orchestration, CD for cloud native environments is often called "GitOps." ArgoCD and FluxCD have become popular choices in this domain. They provide a pipeline that supports tools like Helm and Kustomize to manage app deployments in a Kubernetes-native manner.
Helm is a popular package manager for Kubernetes. It is very common for community supported projects to provide Helm charts to deploy them. So, if you want to use them as a support service or a part of your app stack, you can readily plug them into your GitOps system. Argo and Flux support Helm.
If you're using Kubernetes to run your apps, GitOps systems fit in nicely since they run on K8s too! Plug them into the git repo where you define your Helm charts and away you go.
If a community-supported Helm chart doesn't support some parameterization that you need in your environment, GitOps systems have a solution that doesn't require you fork the upstream Helm chart. Maintaining a fork makes keeping your version up-to-date with upstream improvements difficult and time consuming. With Argo, you can use Kustomize to define custom overlays that update the rendered manifest produced by the Helm chart. In this manner, you can use the community-supported Helm chart and make added tweaks using Kustomize at the next step in the pipeline.
The first challenge is leveraging Helm in conjunction with Kustomize. GitOps systems provide this feature for good reason as mentioned above. However, in practice, it can become a bit of a rats nest. When a misconfiguration occurs, you have multiple steps in the pipeline where the mistake could have been made. Maintenance and troubleshooting become more and more of a maze the more this pattern is applied.
Also, applications running in Kubernetes commonly have dependencies that aren't defined by Kubernetes resources. If you provision and manage S3 buckets on AWS with Terraform, managing that dependency with a GitOps systems is more challenging. You can migrate to using a Kubernetes controller to manage cloud resources, but that migration could be painful. And in any case, you'll still have to provide some orchestration glue that takes outputs from infrastructure provisioning to feed into your app configuration. For example, if you use S3 bucket as an app dependency, when you provision the bucket you'll need to get the bucket endpoint as an output and provide that to your app.
Git as the source of truth is not ideal for this use case. Git is a fantastic human interface for developers managing source code for an application. Configuration of software delivery should be primarily a programmatic operation. To use our S3 bucket example, when the bucket is provisioned, the bucket endpoint output should be programmatically written to the config of the Kubernetes resource/s for the app that will use it. Copy-pasting into text files in a git repo using your IDE is terribly toilsome and prone to error. So if you use some orchestration glue in a script or program, that program has to write to a git repo. Databases are far more appropriate when programs need to have read and write access.
Like all things, GitOps has trade offs. It has been the state of the art for software delivery in cloud native environments but as software delivery becomes more complex, it has proven less and less adequate.
At Qleet, we're developing an alternative approach we call "Application Orchestration." Threeport is the application orchestrator we've developed as an alternative to pipeline-based software delivery like CD and GitOps.
Threeport is a unified system that manages all the dependencies of your app - along with delivery of the app itself. Those dependencies include:
Importantly, Threeport is an extensible system that allows you to add custom abstractions for your most mission critical software. It reduces toil and increases reliability.
Qleet is a managed Threeport provider. Threeport is easy to try out for testing and research, however Threeport is a complex control plane that is non-trivial to run for production purposes. Qleet provides a managed Threeport service so that you can rely on us to keep your Threeport control plane available for you to use.