Konfig Hierarchy
Konfig is structured around a hierarchy which maps closely to both the organizational layout of a business and the corresponding infrastructure in GCP and GitLab. This hierarchy is central to how Konfig manages governance, security, and resource provisioning. It enables Konfig to enforce best practices for access management and cloud governance while also providing clear cost visibility and a streamlined development experience through GitOps. This facilitates a DevOps model with significantly more standardization, structure, and efficiency.
Konfig maintains a consistent structure between GitLab and GCP based around this hierarchy. In GCP, a Control Plane maps to a folder within your GCP organization. Within this folder, there is a folder for each Platform. Within each Platform folder, there are folders for each Domain which contain a project for each environment (e.g. dev, stage, and prod). The image below shows an example of the Konfig hierarchy in GCP.
In GitLab, a Control Plane maps to a subgroup within your organization's top-level group. Within this subgroup, there is a Control Plane project which houses the definitions for the Platforms and Domains the Control Plane manages. This project is preconfigured with a CI/CD pipeline that applies these YAML definitions to the Control Plane. In addition to the Control Plane project, the Control Plane subgroup contains a child subgroup for each Platform. Like the GCP structure, these Platform subgroups in turn contain subgroups for each of the Platform's Domains. It's in these Domain subgroups that actual Workload projects go. Konfig provides a GitLab template for creating new Workload projects that includes a fully functional CI/CD pipeline which applies Workloads to the Control Plane and Workload definition for configuring service settings and infrastructure resources. The image below shows an example of the Konfig hierarchy in GitLab.
Control Plane
The Control Plane is the top level in the Konfig hierarchy. It orchestrates and manages the entire infrastructure and Workload deployments across Platforms and Domains. The Control Plane constantly reconciles the desired state, as specified in YAML configurations, with the actual state of the world and corrects any drift.
The Control Plane is provided to customers as a dedicated managed SaaS which securely connects to a customer's cloud environment and GitLab. All operations which mutate the Control Plane are performed via GitOps. YAML definitions are created or modified in a Control Plane repository in the customer's GitLab and a CI/CD pipeline in this repository applies the changes to the Control Plane.
You can also interact with the Control Plane in a read-only fashion using either the Konfig UI or Konfig CLI.
Platforms
Platforms represent broad organizational boundaries such as business units or major product lines. Each Platform is defined within the Control Plane and serves as a container for multiple Domains. In GCP, a Platform corresponds to a folder within your organization, while in GitLab, it maps to a subgroup. Platforms primarily serve as an organizational construct which allow you to apply common governance and access management settings that cascade to Domains.
Domains
Domains are subdivisions within Platforms that group related Workloads in a fashion modeled after Domain-Driven Design. A Domain might represent a specific product feature or a functional area within a business unit. In the Konfig hierarchy, Domains manage the Workloads and resources specific to their function, ensuring that services within a Domain are logically grouped and governed. Each Domain is configured with a set of Environments (e.g., dev, stage, prod). The combination of Domain and Environment maps to a project in GCP which are contained within a Domain folder. In GitLab, a Domain results in a subgroup within the Platform group in which Workload projects will go.
Domain-Driven Design (DDD) is a software development approach that focuses on modeling software closely around the business domain, using collaboration between developers and domain experts to ensure the software aligns with the business's needs.
Workloads
Workloads are the individual services or applications deployed within a Domain. Each Workload is defined by a declarative YAML configuration that specifies the service's infrastructure needs, such as databases, storage, or compute resources, and runtime settings. Workloads are configured with their own service accounts, ensuring least-privilege access to resources.
Resources
Resources are the infrastructure resources that a Workload relies on such as databases, caches, queues, storage buckets, etc. They are managed declaratively within a Workload's YAML configuration. Konfig handles provisioning Resources for a Workload and configuring IAM on the Workload's service account such that it can access its resources securely and in a least-privilege manner. Resources can be shared between Workloads or Workloads can have exclusive ownership. Resource Templates provide a means to abstract resource configuration from developers and enforce organizational standards.