At Soeldner Consult, we have been navigating the complexities of Cloud technologies since our inception in 2010. Over the years, through countless Cloud Management projects, our focus has remained constant: not just automating IT infrastructure, but bringing a true „cloud experience“ directly to developers and business departments.
As a longstanding VMware/Broadcom partner, our natural starting point was Aria Automation (formerly vRealize Automation). Its core value was the Service Catalog—exposing cloud offerings to users outside the IT department. Whether it was provisioning virtual machines or setting up advanced XaaS (Anything-as-a-Service) architectures, the benefit was undeniable: cutting wait times from weeks to mere minutes.
Today, while Cloud Computing is mainstream, true Self-Service remains an elusive goal for many large organizations. Yes, a highly skilled DevOps team can spin up infrastructure quickly. But in complex enterprise environments, DevOps cannot handle everything in isolation. Dependencies are everywhere:
- Onboarding: Every new application needs a dedicated Cloud project.
- IAM & Security: Developers need specific IAM accounts and roles, which are strictly managed centrally.
- Networking: Firewall management remains a notorious enterprise bottleneck.
Despite massive investments in automation, the developer experience often remains frustratingly slow. You’ve adopted Terraform, your code is in Git, and your CI/CD pipelines are humming. On paper, your infrastructure is modernized. Yet, in reality, your developers are still waiting three days for a simple staging environment or a Google Kubernetes Engine (GKE) cluster. Why?
Because many organizations haven’t actually eliminated manual provisioning; they have simply masked it behind Jira or ServiceNow. Welcome to the Ticket-Ops anti-pattern.
In this first part of our series on scaling Infrastructure as Code (IaC), we analyze why the traditional IT request model is breaking modern delivery pipelines, and why scaling Terraform requires a fundamental shift in how we think about infrastructure operations.
What is Ticket-Ops?
Ticket-Ops is an IT operational model where developers must file a support ticket to request infrastructure changes, access, or provisioning. Instead of relying on self-service automation, a central operations or DevOps team manually reviews, approves, and executes the code (such as running terraform apply) to fulfill the request.
While this model initially feels safe and controlled, it quickly becomes the primary bottleneck in any rapidly growing engineering organization.
The 3 Core Bottlenecks of Ticket-Ops
For Technical Leads and Platform Architects, the pain points of ticket-driven infrastructure manifest in three critical areas:
1. The Context-Switching Tax (Ops Burnout) Your highly skilled DevOps engineers are reduced to „Terraform button pushers.“ Every time an engineer stops architecting to process a routine ticket for an S3 bucket or a DNS record, they suffer a context switch. This cognitive load drastically reduces productivity and leads to operational burnout. While processing a single ticket a day is trivial, reality often looks different. We have seen situations where massive influxes of requests bring operations to a standstill. In one instance at a large enterprise, a service required IAM role assignments across 30 different projects, each needing a multitude of specific roles. It ultimately took an entire night shift just to manually process the tickets and ensure the go-live wasn’t delayed.
2. Time-to-Market Delays (Dev Frustration) Modern cloud-native development thrives on agility. If a developer needs an ephemeral database to test a microservice, a 48-hour SLA for ticket approval completely breaks their flow. The result? Developers either sit idle, wasting expensive engineering hours, or they build workarounds (Shadow IT). While Shadow IT might temporarily reduce time-to-market, it is fundamentally unviable in regulated environments and ultimately introduces massive operational and security toil for the organization.
3. The Illusion of Governance Many organizations cling to ticketing systems under the false assumption that they guarantee security and compliance. In truth, manual reviews are highly susceptible to human error. A tired engineer reviewing a massive terraform plan output on a Friday afternoon is not a reliable security gate. In practice, many organizations fall into the trap of „rubber-stamping“—approving tickets without thorough checks just to clear the backlog. True, robust governance requires automated policies, not manual ticket approvals.
The Terraform Scaling Problem
Terraform is an exceptionally powerful tool, but it was designed for defining infrastructure, not for organizational workflow management.
When you scale Terraform across multiple teams while relying on a centralized Ops team, you inevitably run into:
- State File Conflicts: Multiple tickets modifying the same monolithic state file simultaneously, leading to locked states and pipeline failures.
- Module Drift: Inconsistent use of modules because there is no centralized, easily accessible self-service catalog.
- Lack of RBAC (Role-Based Access Control): Developers cannot safely trigger infrastructure deployments themselves because they require overly broad IAM permissions to run the IaC directly.
Ticket-Ops vs. Platform Engineering
To eliminate this bottleneck, leading engineering teams are shifting away from Ticket-Ops and moving toward Platform Engineering.
| Feature | Ticket-Ops (The Bottleneck) | Platform Engineering (The Future) |
| Trigger | Manual ticket creation (Jira, ServiceNow) | Developer Self-Service Portal (e.g., Backstage) |
| Execution | Centralized DevOps team runs the code | Automated GitOps pipelines |
| Governance | Manual review by a human | Automated Policy-as-Code checks |
| Lead Time | Days to Weeks | Minutes |
The Paradigm Shift: Building an Internal Developer Platform (IDP)
The goal is not to stop using Terraform or Git. The goal is to wrap these tools in an Internal Developer Platform (IDP). By providing developers with a self-service catalog of pre-approved infrastructure templates, you empower them to provision what they need, exactly when they need it—while the platform enforces security and governance automatically in the background.
In Part 2 of this series, we will dive deep into the technical implementation. We’ll explore how to structure your Terraform modules, manage state at scale, and introduce true self-service using modern tools like GitOps Director to eliminate the ticket queue once and for all.
Stop waiting for infrastructure. Learn how GitOps Director empowers your platform teams to deliver sovereign, self-service infrastructure in minutes, running natively on Spotify Backstage.