Why GitOps Alone Isn’t Enough: The Rise of Imperative Workflows in Platform Engineering

GitOps changed the game when it was introduced in 2017, offering a simple, powerful model for declarative deployments using Git as the source of truth. But as platform engineering matures—and developers demand faster, safer self-service—the GitOps model is revealing its limitations.

Championed by the now-closed company, Weaveworks, GitOps is a practice of deploying applications using Git as the single source of truth. Since its creation, several tools (Flux CD, ArgoCD, etc.) have emerged to enable organisations to implement GitOps, all with different approaches.

In this article, we’ll explore why GitOps would benefit from a complementary set of tools to support imperative workflows. From multi-environment promotion to provisioning non-Kubernetes resources, it’s time for a new era of platform orchestration.

Where GitOps starts to break down

Much like the Unix philosophy design principle, which states that software should do one thing and do it well, GitOps tooling was created to do one thing and do it well. However, the problem it was initially designed to solve has evolved, and chances are your organisation doesn't just want to deploy applications to a single environment.

Typically, you want to promote deployments through a pipeline of environments, from development to staging to production.

While ArgoCD has plugins like the Image Updater and various promotion workflows, these solutions feel bolted-on rather than native. At the same time, you might find yourself trying to bend ArgoCD’s ClusterWorkflowTemplate resource to handle cross-environment promotions, creating elaborate webhook chains, or writing custom controllers that watch for successful deployments in one environment before triggering the next.

The evolution of GitOps: Imperative workflows

So far, we have established that GitOps, while successful at creating a solid foundation for deploying applications, is now encountering the limits of its original design as the problem space evolves. 

The rise of platform engineering has fundamentally shifted what teams expect from their deployment tooling; it is no longer sufficient to simply reconcile desired state within isolated environments.

Platform teams are now responsible for orchestrating workflows, such as the promotion-based example highlighted earlier and empowering teams to self-serve resources that exist outside Kubernetes. 

So, how exactly can imperative workflows help?

Take a step outside the Kubernetes ecosystem for a moment, and you'll find that many workflows do not define the end state but rather how it should occur through a series of scripts or shell commands; that is, the configuration is imperative rather than declarative.

GitOps tooling within the Kubernetes ecosystem has, for the longest time, shielded us from much of the same (imperative) fate. When I define a deployment with two replicas, I do not specify to Kubernetes which node (except if I really want to) to run the pods on. It just happens.

Custom Resource Definitions (CRDs) were a significant leap in enabling many of the marvels of platform engineering we have today; however, stitching all of your applications, environments, and platform components together is where imperative workflows come in.

This is precisely where frameworks like Kratix demonstrate what's possible when you combine declarative principles with imperative workflow orchestration. In Kratix, a Promise defines a service, such as a database, where all the logic to provision, configure, and manage that database is encapsulated within the Promise definition. The developer requesting the database doesn't need to understand the underlying complexity of storage classes, backup policies, or networking configurations.

This separation enables platform teams to encode their operational knowledge and compliance requirements into reusable, imperative workflows, while maintaining the simplicity that made GitOps appealing in the first place.

What imperative workflows enable

While GitOps will remain central to enabling declarative workflows, it is just one step in the pipeline, as imperative workflows will allow platform teams to build truly composable solutions.

Instead of writing custom scripts for each service, teams can create reusable pipeline components, such as a "database provisioning" workflow, which can be combined with an "approval gate" workflow and a "security scanning" workflow to create different service offerings.

This flexibility means you're no longer constrained to pure GitOps reconciliation. A single imperative workflow might leverage Crossplane to provision and manage external resources, such as an S3 bucket or a secret manager, pause for security approvals, and then continue with additional GitOps steps. 

Most importantly, Git remains the source of truth, but orchestration happens elsewhere.

Why should platform engineers care?

Platform engineering marks a full-circle moment for DevOps and the cloud-native ecosystem.

First, we built a reliable container orchestration layer using Kubernetes, created CRDs to teach it about external resources, and followed GitOps to ensure we have a versionable and single point of reference for deployments.

Imperative workflows will stand as a means to enable teams to build platforms that fit into the various dynamics of their organisation and, more importantly, allow self-service.

Rather than forcing every team to adopt the same rigid deployment pipeline, platform engineers can define workflows that accommodate different compliance requirements for various business units, or create fast-track workflows for internal tools while maintaining stricter gates for customer-facing services.

Declare results, not processes 

GitOps laid the foundation by helping teams version and track desired state, but internal platforms now demand that sync loops and reconciliation mechanics be applied to the wider platform components.

As organisations aim to support fast-moving development teams while meeting compliance and operational standards, imperative workflows offer a practical evolution.

With tools like Kratix, platform engineers can encode expertise, define policies, and support diverse use cases, all without compromising on developer velocity.