As I mentioned in my previous post, we recently rebuilt the tutorial. This was the culmination of several workstreams that were triggered by early feedback.
I want to share a bit more detail about the journey that let us here.
If you are new to ConfigHub, all this may not be very interesting since it just describes our journey. But if you've been following us, then I hope this gives you a bit of useful background behind the recent changes.
Our original idea was this and still is: If you treat configuration as data and build your tooling on this principle, then you can solve a lot of the problems that Platform Engineering, DevOps, IT and Tech Operations teams are dealing with when deploying software at scale.
Our original implementation was "shapeless" config in a database. This was on purpose. The power of the database approach is that you can layer any dimension you want over the data: which logical component is it part of, what cluster is it deployed to, who owns it, which layer is it part of, and so on. Everything is just a SQL(ish) query or a bulk mutation.
Components, Variants and Targets
It became clear that we needed to add some structure to this in order to make it approachable. We think the 3 most important structural concepts are Components, Variants and Targets. The key to the database approach is to not make this structure a straightjacket. We have layered these concepts onto config in a lightweight way and you can still mutate and work with config along any dimension you want using queries and bulk operations (basically SELECT and UPDATE ... WHERE ... if you're a SQL person).
A component is a logical grouping of software pieces that are not tied to a particular deployment. It can be an API service including its Redis and Postgres backing stores, or it can just be the API service itself with dependent services living in other components.
The granularity of a component depends on deployment needs, sequencing requirements, ownership, lifecycle and other concerns. Another commonly used term for this is "App". But we think component is more appropriate because in most cases a component is just that, a part of a whole composition and not standing alone.
A variant is a copy of all the configuration for a component that either 1) is meant for deployment to a specific target or 2) serves as a base for other deployments.
A target is what variants are deployed to. Because we are mostly Kubernetes focused, this is almost always a Kubernetes cluster. But it could be any kind of infrastructure service that can receive configuration and provision resources based on it.
If you are familiar with GitOps, then you can think about it the following way. A component is what you define in git. A variant is a single rendering of this component targeted at a single cluster which typically has its own Argo App or Flux Kustomization. The Target is the cluster itself.
If you are familiar with Heroku, then a variant is a Heroku app. It is a specific deployment. You probably have a pattern like myapp-dev, myapp-staging and myapp-prod in your Heroku account. This is because Heroku doesn't have a concept that maps to component. It's just a pattern (which is totally fine). A pipeline can somewhat serve this purpose. The target would be the EU or US common runtimes or a Private Space.
If you go through our tutorial, you will see that ConfigHub now has a clear representation of these concepts. That will make it easier to manage more config at larger scale.
Goodbye Bridge Protocol
The second big thing we changed is aligning to existing GitOps operators. From the early days, ConfigHub always had support for deploying via Flux (and later on ArgoCD). We decided to make this the only way you deploy config with ConfigHub. This allows us to focus on building an intuitive and robust experience for existing Flux and ArgoCD teams. It removes unnecessary cognitive barriers because you don't have to also understand how ConfigHub might deploy things. It just does it the Flux or Argo way.
Perhaps the biggest change we made was to abandon what we called the bridge protocol. The motivation behind the bridge protocol was that clusters need to communicate with a configuration store in a two way manner. GitOps operators are one-way only and git has limitations as a config store. We wanted to define a protocol that allows users to build a variety of bridge workers running in clusters and exchanging data with ConfigHub in both directions.
Hello OCI
Our first take on this two-way communications mechanism turned out to be too rigid and overlap too much with GitOps operators. We decided to split up the problem. For moving config to clusters, ConfigHub now acts as an OCI registry. Flux, ArgoCD and other similar tools can pull config from ConfigHub using the OCI protocol, just like they would from Github's ghcr.io, JFrog Artifactory, AWS ECR, and so on.
For reporting information back to ConfigHub, we use a "bot" pattern where you deploy a small watcher to the cluster which reports back various forms of information to ConfigHub. The first example of this is argobot. This decoupling creates more flexibility, familiarity and robustness. For example, bots can be entirely optional and can fail without causing issues with the primary deployment path.
Plotting the path ahead
Software deployments power everything around us: energy infrastructure, transportation, governments, payments, communications, business tools, self-driving cars, AI apps, and more. Redefining how to manage software deployments is not for the faint of heart. But we firmly believe that the current tools and practices are not sufficient to take us through the AI-fueled hockey-stick moment that is already unfolding.
We are still defining what this next-generation tool will look like. We hope you will join us on the journey ahead. Start by signing up, walk through the tutorial, and give us feedback on Discord or at hello@confighub.com.
Hero image generated with Gemini based on a picture of Catalina Harbor taken by me.