In the first part of this series, we explored the hidden costs of „Ticket-Ops.“ We discussed how masking manual infrastructure provisioning behind Jira or ServiceNow creates a massive bottleneck. It burns out operations teams with repetitive tasks and frustrates developers with days of waiting for simple environments.
Recognizing the bottleneck is the first step. The next is architecting the solution.
Moving from a centralized, ticket-driven model to a decentralized, self-service Internal Developer Platform (IDP)requires a fundamental shift in how we structure and execute our infrastructure and configuration management. You cannot simply hand over the keys to your entire cloud environment and hope for the best.
As described, in many private cloud computing environments we have built such solutions based on VMware Aria Automation. However, this is solution is mainly built for a VMware centric environment and is quite difficult to support resources beyond virtual machines, we were looking for a different solution.
Internal Deveper Platforms became quite popular in the 2020s, however we quickly realized that they were too generic to support Ops Self-Service out-of-the-box.
On the other hand, Backstage as a framework for building an Internal Developer Platform already brings all the necessary features to build GitOps Director – our next-generation GitOps Portal.
The idea is quite simple: Don’t reinvent the wheel and use GitOps best practices. On top of that, GitOps Director will simply do the rest and provide the Self-Service experience needed for enterprises.
In this second part, we dive into the technical implementation GitOps basics: How to structure Infrastructure as Code (IaC) for scale, how to avoid vendor lock-in, and how to use modern GitOps practices to enable true developer self-service without compromising security.
Break the Monolith: Decentralized State Management
The most common reason Ops teams refuse to let developers trigger automation directly is the fear of the „blast radius.“ If your entire cloud environment—VPCs, Kubernetes clusters, and databases—is managed in a single, massive terraform.tfstate file or a monolithic Ansible inventory, one wrong configuration can take down production.
To scale automation safely, you must adopt a micro-state architecture:
- Decouple by Lifecycle: Separate foundational infrastructure (networking, core IAM) from application-specific infrastructure (S3 buckets, Redis instances, specific namespaces).
- Isolate by Environment: Development, Staging, and Production must remain strictly isolated.
- Limit the Blast Radius: When states and inventories are small and modular, the impact of an error is confined to a single application or component. This modularity makes it safe to hand over control to development teams.
In order to achieve that, you should set up your Git structure accordingly. For example, in GitLab you can create groups, subgroups and projects to model this accordingly. In addition, you can use Gitlab’s RBAC features to assign permissions only to those artifacts where needed.
The following figure shows that a structure. The cloud-management service contains a sub-folder for all Google Cloud related services, whit each stage separated. Terraform deployments are prefixed with the deployment keywordl
Figure 1: GitLab structure
Define „Golden Paths“ Across a Multi-Cloud Landscape
Self-service does not mean the Wild West. Developers shouldn’t have to write raw HashiCorp Configuration Language (HCL) or complex Ansible playbooks from scratch, guessing which security groups to apply or which instance types comply with company policies.
Instead, Platform Engineering teams must provide Golden Paths—curated, pre-approved infrastructure templates that embody the company’s best practices.
Crucially, a modern platform must be tool-agnostic and multi-cloud capable. Developers typically don’t care whether an environment is provisioned via Terraform on AWS, configured via Ansible on a sovereign on-premises VMware cluster, or deployed via Argo CD into Kubernetes. They just need the environment.
By building Golden Paths, you create an abstraction layer:
- Avoid Vendor Lock-in: The underlying automation logic is decoupled from the developer request. If your organization decides to move a workload from a hyperscaler to a local, sovereign data center, the developer experience remains identical.
- Tool Flexibility: Use the right tool for the job. Terraform for cloud infrastructure, Ansible for OS-level configuration, and Argo CD for Kubernetes workloads—all orchestrated through a single unified catalog.
We have good experience with platform engineering teams that provide those artifacts in a single location in Git, so that all other teams can consume those elements. This can look like the following:
Figure 2: GitOps structure for Golden paths, infrastructure templates, etc.
The Shift to GitOps: Automation over Execution
Even with micro-states and standardized modules, how do developers actually trigger the deployment? Handing out broad IAM permissions to developers so they can run terraform apply or ansible-playbook locally is a massive security risk.
The answer is GitOps.
In a GitOps model, Git becomes the single source of truth. Developers (or the self-service platform) do not interact with the cloud provider APIs directly. Instead, they commit configuration changes to a Git repository. A CI/CD pipeline or a GitOps operator detects the change, plans the execution, and applies it.
The security gate is no longer a human reading a Jira ticket; it is a Pull Request / Merge Request (PR/MR) backed by automated checks.
Figure 3: Gitlab CI Pipelines
Bridging the Gap: The Role of an Internal Developer Platform
Here is the final hurdle: Most developers do not want to construct complex directory structures or manually write Git commits just to request a PostgreSQL database. They want a frictionless UI.
This is where an Internal Developer Platform (IDP), typically built on frameworks like Spotify Backstage, becomes crucial. However, Backstage alone is just a frontend catalog. It needs an intelligent engine to translate user inputs into infrastructure code and orchestrate the GitOps workflow.
Enter GitOps Director
To seamlessly connect the developer UI with your diverse automation tools, you need an orchestrator. This is exactly what we designed GitOps Director to do.
Instead of writing a ticket, the workflow becomes a matter of minutes:
- Self-Service Selection: A developer logs into Backstage and selects a template (e.g., „Production Microservice Environment“).
- Form Input: They fill out a simple UI form, completely abstracted from the underlying code.
- Automated Translation: GitOps Director intercepts this request and automatically generates the correct, module-compliant code—whether that is Terraform HCL, an Ansible playbook, or Argo CD Kubernetes manifests.
- Zero-Touch MR Creation: GitOps Director automatically structures the repository and opens a Merge Request in GitLab or GitHub.
- Automated Execution: CI pipelines run Policy-as-Code checks. Once passed, the infrastructure is deployed automatically via your existing GitOps runners.
The Result: Sovereign, Zero-Manual Ops
By combining decentralized state management, tool-agnostic Golden Paths, and the GitOps Director, you achieve the holy grail of Platform Engineering: Zero Manual Ops.
Developers get their infrastructure in minutes. Platform engineers stop processing routine tickets and return to high-value architectural work. Most importantly, your organization retains full control over its data and infrastructure, enabling true sovereign cloud strategies across any environment.
Stop waiting for infrastructure. Start building platforms. > GitOps Director is the native Backstage solution built by Soeldner Consult from 15 years of enterprise experience. Enable true self-service, enforce sovereign cloud governance, and orchestrate Terraform, Ansible, and Argo CD seamlessly. [Request a free demo today.]