It’s Time to Stop
‘Providing Infrastructure’ and
Start Building a ‘Development Platform’

In my role at AllCloud, I meet with dozens of organizations every year. In almost every one, I hear a variation of the same story: development teams feel “stuck” waiting for infrastructure, and DevOps/cloud teams feel like they’re “drowning” in tickets and urgent requests.

The classic dialogue goes something like this:

• Developer: “I need a new testing environment for microservice X.”
• DevOps: “Open a ticket, we’ll get to it. We’re swamped.”
• The Developer (three days later): “What’s the status of my environment? The feature is blocked.”
• DevOps: “I set it up for you. Oh, wait, I forgot to open access to the DB… and I need to configure an IAM role… and make sure the security group is correct…”

The result? Mutual frustration, wasted time, and a direct delay in the product’s time-to-market.

The problem isn’t technical; it’s conceptual. Many organizations still operate in a reactive “infrastructure as a service” model, where the infrastructure team is a passive service provider. It’s time for a paradigm shift. The solution we champion for our clients is the move to platform engineering: transforming the infrastructure team into a team that builds an internal product—a governed, self-service development platform.

The AWS cloud offers infinite flexibility, but it also introduces complexity. Without proper governance, we end up in one of two problematic scenarios:

1. “The Wild West”: Developers are given overly broad access. The result is chaos – a lack of uniformity, security holes, wasted resources, and an inflated monthly bill that no one understands.
2. “The Fortress”: The DevOps team locks everything down. Every small change requires approvals, tickets, and waiting. The result is a human bottleneck that slows down the entire organization and stifles innovation.

Both scenarios are bad for business. The goal of platform engineering is to find the “golden path”: to enable developers to move fast and safely within a well-defined framework.

When we at AllCloud design such a platform for a client, we leverage the right tools to build an efficient workflow.

The core idea is abstraction. The developer doesn’t need to know how to build VPCs, subnets, and IAM roles. They need to be able to request a “Single Page Application environment” and get it in minutes, already incorporating all the organization’s best practices.

Here’s how we do it:

1. The Foundation: Infrastructure as Code (IaC) and “Golden Paths”

We start by defining standardized building blocks using Terraform (or AWS CDK). These are our “Golden Path Modules” – reusable components that represent approved organizational infrastructure. Each module already contains the required security rules, tagging (for FinOps and cost allocation), and monitoring configurations.

Examples of such modules could be a “secure RDS module,” an “organizational EKS cluster,” or a “Single Page Application template” (which includes an S3 Bucket, CloudFront Distribution, and security settings).

2. The Infrastructure “Store”: Start with GitOps, Evolve to a Catalog.

This is the key to success. How does a developer “purchase” infrastructure from the “store”?

The First Phase: We implement a pure GitOps approach. The “catalog” is simply configuration files in Git.

• Requesting Infrastructure: A developer who wants a new database doesn’t open a ticket. They simply clone an approved Terraform module (the “Golden Path”) configuration file template from Git and insert the parameters relevant to their application.
• The Approval: They make a git commit and open a Pull Request.
• The Automation: A CI/CD pipeline (e.g., in GitLab CI) automatically kicks in, runs a Terraform plan, and shows the developer exactly what is about to change.
• The Governance: After the PR is approved, the developer (or team lead) is required to manually approve the Terraform apply step. This is a critical control point that maintains full oversight.

In more advanced stages: Once this basic process is working and adopted, we can add another layer of abstraction on top of this GitOps flow using an Internal Developer Portal (IDP) like Backstage or Quali. At this stage, the developer doesn’t even write the configuration file. They select a “product” from a visual catalog, fill out a simple form, and at the click of a button, automatically generate the pull Request in Git behind the scenes.

In both cases, the core principle remains: governed automation based on IaC and Git.

3. Clear Roles & Responsibilities (R&R)

The technology won’t work without a clear definition of responsibilities:

• Landing Zone Team: Responsible for the “highways” – AWS accounts, the core network (VPCs), and global security policies.
• Platform Team: The “manufacturer.” They build and maintain the “Golden Path Modules.” They own the CI/CD pipelines.
• Development Team: The “customer.” They consume the ready-made modules to assemble the infrastructure required for their application.

4. Separating Pipelines: Platform CD vs. Application CD

We enforce a strict separation between deploying infrastructure and deploying the application.

• Platform CD (based on Terraform & GitLab CI): Responsible for provisioning the resources in AWS (the EKS cluster, the DB, and the S3 bucket).
• Application CD (e.g., based on ArgoCD): Once the infrastructure exists, ArgoCD takes over. It “watches” the application’s Git repo and is responsible only for deploying the code (the Docker image) into the EKS cluster.

When we implement a platform approach for our customers, the change is felt immediately across the entire organization:

• Reduced Time-to-Market: The time required to set up a new environment drops from weeks to minutes. This is the most critical business metric.
• Drastic Improvement in Developer Experience: Frustrated developers become happy and productive. They focus on writing code and solving business problems, not on infrastructure bureaucracy.
• Compliance and Security by Design: Instead of chasing developers who  forgot to store their application secrets in Secrets Manager (and hard-coded them in a config file instead), security and compliance are built into the “Golden Path Modules.” Organizational risk is dramatically reduced.
• Empowered Platform/DevOps Teams: These valuable teams stop fighting fires and start innovating – optimizing costs, improving performance, and building more advanced Golden Paths.

The transition to Platform Engineering is a journey, not a destination. This is where we come in. At AllCloud, we don’t just help select the right tools, we guide the organization in defining the Governance Framework, drawing the lines of responsibility (R&R), and building the first Golden Paths that will lead to real change.

If you also feel that infrastructure bottlenecks are holding you back, maybe it’s time for you to stop “providing infrastructure” and start building a platform.

What is the most significant bottleneck in your development lifecycle today? And how are you planning to address it? 

Ready to move from providing infrastructure to building a Platform? Contact AllCloud today to get started.