From Friction to Flow: How GitOps and Control Planes Are Transforming Dev and Ops Collaboration

The management of infrastructure and applications has evolved dramatically in recent years. Traditionally, development and operations teams had to work closely to define and deploy both code and infrastructure, which often led to friction. However, with the rise of new technologies and approaches such as GitOps and control planes, we’re witnessing a shift that reduces these pain points. Now, responsibilities between developers and operators can be decoupled more efficiently.

Before the API: The Traditional Approach

Even today, many organizations operate in a model where there’s no clear separation between the roles of developers and SREs (Site Reliability Engineers), leading to operational friction. In this "before the API" approach, the same Terraform scripts or Kubernetes manifests that define infrastructure are maintained alongside the application code in the same repositories. These manifests include both the high-level definitions that developers care about—such as the stack and application resources—and the low-level operational details, like infrastructure configuration and scaling policies, which are critical to SREs.

This lack of clear division between what developers need (high-level definitions of applications and resources) and what operators need (infrastructure management, scalability, and operational concerns) forces both roles to work on the same set of artifacts, such as deployment scripts and manifests. This creates friction because these artifacts combine responsibilities that should be separated.

For example, a developer might modify a manifest to adjust application settings, but this same file might also contain critical information about infrastructure state or scaling rules, which directly concern the SRE team. Without a well-defined contract—an API—between the developer and the operations team, everyone needs to know and understand both the application and the infrastructure in detail, creating operational bottlenecks and increasing complexity.

Historically, tools like Puppet, Chef, and Ansible introduced state consolidation, where the desired state of infrastructure was defined and managed over time. But with the rise of CI/CD pipelines and Infrastructure as Code (IaC) practices like Terraform and Kubernetes manifests, the focus has shifted towards execution, with developers and SREs working on the same codebase, often without clear role boundaries.

In this "before the API" world, there is no distinct separation of concerns or contracts that define the interface between development and operations. This results in increased friction, as developers have to account for operational details they shouldn’t need to worry about, and operators must keep track of application-level configurations that might change frequently. This blending of responsibilities leads to unnecessary complexity and slows down both development and operations.

After the API: The Rise of Control Planes

With the advent of Kubernetes and the concept of control planes, a new way of managing infrastructure and applications emerged that solves many of the issues from the "before the API" world. Kubernetes introduced a standard API not just for defining and managing applications, but also for extending capabilities through Custom Resource Definitions (CRDs). This effectively established a clear contract between developers and operators, allowing each group to focus on their distinct responsibilities without the need for deep knowledge of each other’s domains.

In the "after the API" approach, developers can now focus purely on defining high-level resources, such as applications, secrets, or environments, using well-defined APIs. This means they no longer need to understand or manage the underlying infrastructure directly. On the other side, operators or SREs are responsible for ensuring that these high-level definitions are correctly consolidated and executed in the infrastructure, using the control plane and tools like GitOps to manage the actual deployment and scaling.

CRDs play a critical role in this separation. By allowing teams to define custom resources that abstract the underlying infrastructure, developers can focus on describing what they need at a high level (e.g., "I need a database" or "deploy this application") without worrying about how those resources are provisioned or managed. The control plane, via CRDs and operators, ensures that these definitions are translated into actionable instructions for the infrastructure, automating the entire lifecycle of resources.

The "after the API" model represents a major shift: developers no longer have to manage infrastructure details like networking, scaling, or persistent storage—they simply describe what they need via API. Meanwhile, operators maintain control over how those requests are fulfilled, ensuring infrastructure stability, performance, and security. This separation minimizes friction by allowing each role to focus on what they do best, streamlining collaboration.

For example, a developer can define an application deployment with Kubernetes YAML files, while the actual infrastructure required to run that application (like autoscaling, load balancing, and storage) is managed by operators who rely on CRDs and GitOps to ensure the infrastructure is provisioned correctly. The result is that developers can work at a high level of abstraction, while operators use Kubernetes’ API and control plane to ensure everything runs smoothly.

In essence, the control plane becomes the layer that decouples high-level resource definitions from the low-level details of how those resources are implemented, introducing a clean separation of concerns that didn't exist before.

GitOps and Orchestration via Controllers

In the "after the API" model, GitOps plays a critical role by ensuring that the desired state of both infrastructure and applications is consistently managed and versioned. GitOps operates by declaring the desired state of resources (infrastructure, applications, secrets, etc.) through manifests and Custom Resource Definitions (CRDs), which are stored in a Git repository. GitOps continuously reconciles the actual state of the system with the desired state, ensuring that any drift is corrected and that the system stays aligned with the declared configurations.

Unlike the "before the API" world, where developers and operators shared responsibility over the same configuration files, GitOps allows for a clean separation by letting developers define high-level resources in Git (such as apps, environments, or secrets), while operators handle the reconciliation and management of the infrastructure. This is done in a secure and reliable manner, with Git acting as the source of truth. Kubernetes controllers periodically pull the desired state from Git, ensuring the current state in the cluster matches what is declared, and applying any necessary changes automatically.

Developers interact with Kubernetes by defining resources (like Deployments, Services, and Secrets) or extending functionality with CRDs to create custom resources that fit their application needs. CRDs are the mechanism through which new resource types are introduced, and these resources are then managed and consolidated by Kubernetes controllers. The controllers continuously ensure that the lifecycle of the resources matches the desired state as declared by developers or operators.

GitOps enhances this process by versioning the desired state and automating the reconciliation process, but the real power of Kubernetes lies in its control plane and controllers, which execute the lifecycle management of all declared resources. This separation ensures that developers only need to declare what they need in terms of high-level resources, while Kubernetes, through CRDs and controllers, handles the complexity of how those resources are provisioned, scaled, and managed in the underlying infrastructure.

Thus, GitOps ensures the system’s state remains consistent and secure by continuously pulling and applying the desired state, while Kubernetes’ API and control plane orchestrate the full lifecycle of resources. This eliminates manual intervention, reduces the risk of errors, and ensures that the system behaves predictably across environments.

Decoupling Roles and Responsibilities with CRDs and Control Planes

While GitOps ensures consistency and versioning of the system's desired state, the real power of CRDs (Custom Resource Definitions) lies in their ability to decouple roles and responsibilities across a variety of stakeholders, allowing each to focus on their specific domain without needing to understand the full stack.

With CRDs, you can create resource abstractions tailored to different roles, such as Developers, DevOps, DevSecOps, SREs, Platform Engineers, Network Engineers, Security Engineers, and Architects. Each group can work with the level of abstraction that fits their needs:

• Developers can focus on high-level CRDs that define the applications and services they are building, without needing to know how the underlying infrastructure is managed.
• SREs and Platform Engineers can define and manage controllers that handle the deployment, scaling, and operational lifecycle of those resources in the infrastructure.
• Security Engineers and DevSecOps can enforce security policies and compliance requirements through custom CRDs that automatically apply security configurations and policies.

What makes this approach particularly powerful is the ability to nest CRDs across these roles. High-level CRDs created by developers can trigger intermediate CRDs defined by platform engineers, which then configure infrastructure-level resources like networking, security, and scaling. This hierarchy of CRDs is orchestrated seamlessly by Kubernetes controllers, ensuring that each resource's lifecycle is managed according to its role-specific definition.

By integrating GitOps with CRDs, this layered approach is not only automated but also version-controlled. Each role can define their resources and ensure they align with the overall system's state through Git. Kubernetes controllers continuously reconcile the system to match the declared desired state, ensuring that changes at any level—whether application-level or infrastructure—are automatically reflected.

This decoupling of responsibilities allows different teams to focus on their expertise while maintaining a cohesive, unified infrastructure. Architects can ensure that the overall system design is coherent, while Network Engineers manage connectivity, and Security Engineers apply governance and compliance. All these components are consolidated through Kubernetes' control plane without requiring developers to be involved in the operational details.

The end result is a system where each role works within their area of focus, leveraging CRDs to abstract complexity and maintain operational efficiency, with minimal friction between teams.

Key Technologies for the Future: Kubevela, Crossplane, Helm, Flux, and ArgoCD

The future of infrastructure and application deployment is defined by decoupled control planes and orchestration through GitOps and Kubernetes. As organizations seek more scalable and efficient ways to manage both applications and infrastructure, technologies like Kubevela, Crossplane, Helm, Flux, and ArgoCD play a crucial role by leveraging the Kubernetes API, one of the platform’s most powerful features.

Kubevela enables the transformation of high-level application definitions into CRDs that Kubernetes can consolidate. By abstracting the complexities of infrastructure, Kubevela empowers developers to focus on what their application needs, while Kubernetes manages the underlying resources through its control plane.

Crossplane extends this capability by allowing organizations to construct entire applications using composites, which define both the application and its infrastructure dependencies. Crossplane manages the entire lifecycle of applications and infrastructure as code, making it easy to scale and manage resources in a unified system.

In this ecosystem, Helm continues to play a vital role by providing a way to package applications into reusable, versioned charts. This helps maintain consistency across different environments while managing the full configuration of Kubernetes resources in a template-based format.

But what ties all of this together is GitOps, and here is where Flux and ArgoCD come into play. Both tools enable GitOps by ensuring that the desired state of resources—whether application or infrastructure—is defined in a Git repository and automatically synchronized with the actual state of the Kubernetes cluster. By continuously pulling the state from Git, Flux and ArgoCD make sure that the resources managed by Kubernetes (such as CRDs, Helm charts, or even full applications defined by Crossplane or Kubevela) stay aligned with what is declared in Git. This automated reconciliation process removes the need for manual interventions, significantly reducing operational complexity.

What makes these tools even more powerful is that Flux and ArgoCD interact seamlessly with Kubevela, Crossplane, and Helm because they all rely on the Kubernetes API. The API acts as a common language, allowing these technologies to integrate naturally. This flexibility is one of Kubernetes’ greatest strengths, enabling a unified platform where tools from different layers—such as application deployment, infrastructure management, and GitOps orchestration—can work together effortlessly.

Practical Example: Helm + Kubevela + Flux + TofuController in Action

Let’s consider a scenario where we want to deploy a complete application using Helm, Kubevela, Flux, and TofuController.

1. Helm is used to define the full scope of the application, bundling together everything the app needs, including the application itself, secrets, and infrastructure resources. This creates a comprehensive, high-level view of the application that can be shared across stakeholders.
2. Kubevela comes into play to orchestrate the Custom Resource Definitions (CRDs) that represent different parts of the deployment. For instance, Kubevela can define separate views for the developers (focusing on the application components) and for the SREs (focusing on infrastructure and security configurations). These CRDs are broken down into various levels, allowing each stakeholder to focus on their specific needs while Kubevela ensures the consistency and orchestration of these views.
3. The application part of the deployment is executed at the final stage of the GitOps pipeline using standard Kubernetes manifests, ensuring that the application is deployed consistently across environments. Meanwhile, the infrastructure part is handled at the end of the pipeline by TofuController, which specializes in managing the infrastructure components based on the CRDs defined by Kubevela.
4. Finally, Flux takes care of GitOps consolidation, ensuring that the state defined in Git is reflected in the Kubernetes cluster. Flux watches for changes in the Git repository, applies the updates, and triggers the necessary controllers to maintain the desired state of both the application and the infrastructure.

This approach enables a clean separation of concerns between application development and infrastructure management. Developers focus on the application using high-level definitions, while operators control the infrastructure lifecycle, all within a GitOps framework that ensures consistency and automation.

Conclusion

Decoupled control planes are revolutionizing the way we manage both infrastructure and applications. By enabling developers to focus solely on high-level definitions, and allowing operators to manage the underlying infrastructure through GitOps, CRDs, and Kubernetes controllers, much of the friction that once existed between development and operations is significantly reduced.

The combination of tools like Kubevela, Crossplane, Helm, along with Flux and ArgoCD for GitOps orchestration, ensures that resources are deployed, scaled, and managed in an automated, secure, and efficient way. These technologies are not just improving how applications are deployed—they’re creating an ecosystem where development is faster, operations are smoother, and the entire lifecycle of applications is easier to manage.

As we move forward, these innovations are shaping a future where application deployment and infrastructure management become more agile, resilient, and scalable. The once rigid boundaries between development and operations are giving way to a new paradigm where both can work in harmony, supported by the powerful Kubernetes API and the seamless orchestration of resources.