Platform Engineering May 2020 ยท 6 min read

Self-Service DevOps: The Foundation of Modern Internal Developer Platforms

Before "Platform Engineering" was a job title, DevOps teams were already building the self-service infrastructure that now powers AI-assisted developer workflows.

In 2020, I wrote about how DevOps enables self-service delivery โ€” the idea that developers shouldn't have to wait in a queue to get an environment, spin up a database, or trigger a deployment. The ops team's job, I argued, was to build the paved roads that developers could walk themselves.

Five years later, that idea has a name: Internal Developer Platforms (IDPs). And the teams that built self-service infrastructure early are now miles ahead โ€” because those same platforms are the foundation on which AI-assisted developer workflows are being built.

๐Ÿ’ก Self-service DevOps was never just about convenience. It was about reducing cognitive load, eliminating bottlenecks, and letting engineers focus on what they actually create value doing โ€” building software.

What Self-Service DevOps Actually Means

Self-service doesn't mean "no guardrails." It means the guardrails are baked into the platform rather than enforced by a human approval process. A developer should be able to:

None of this means ops is out of the picture. It means ops built the system that makes all of it possible safely.

The Three Layers of Self-Service Infrastructure

1. Infrastructure as Code (IaC)

The foundation of self-service is treating infrastructure like software. When every environment is defined in code, developers can read it, understand it, and modify it within guardrails. Terraform modules, Helm charts, and CloudFormation templates become the building blocks that teams assemble rather than infrastructure that ops hands down.

dev@team:~$ terraform workspace new feature-auth-service
Created and switched to workspace "feature-auth-service"
dev@team:~$ terraform apply -var-file=dev.tfvars
Plan: 8 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 8 added.
dev@team:~$ # No ticket. No waiting. Deployed in 90 seconds.

2. GitOps and Automated Pipelines

GitOps โ€” using Git as the single source of truth for both application and infrastructure state โ€” is what makes self-service deployments safe. When a developer merges a PR, the pipeline takes over: build, test, scan, deploy. No human in the loop for the routine case. Humans step in for exceptions.

ArgoCD and Flux have made this pattern accessible at any scale. The developer experience is simple: push code, watch it deploy. The ops experience is: define the policy once, trust the system to enforce it.

3. Developer Portals and Service Catalogs

The newest layer โ€” and the one that's accelerating fastest โ€” is the developer portal. Tools like Backstage (open-sourced by Spotify) give developers a single place to discover services, provision resources, view documentation, and understand ownership.

This is where self-service becomes a product. The ops team isn't just running infrastructure โ€” they're building an internal product that developers use every day. That shift in mindset changes everything about how platform teams operate.

Self-Service in the Age of AI

Here's where it gets interesting. The same self-service infrastructure that reduces friction for human developers also reduces friction for AI agents.

When an AI coding assistant (like GitHub Copilot or Claude) helps a developer write code, that code still needs to go through the same pipeline โ€” build, test, scan, deploy. The self-service platform doesn't care whether the code was written by a human or suggested by an AI. The guardrails apply either way.

But there's a new frontier emerging: AI agents that interact with the platform directly. Imagine an agent that:

All of this is possible only if the platform exposes clean, well-defined APIs that both humans and agents can use. Self-service infrastructure isn't just for developers anymore โ€” it's for agents too.

The Bottleneck Was Never the Pipeline

When teams struggle with slow delivery, the instinct is to look at the pipeline. But in my experience, the real bottleneck is almost always approval processes, unclear ownership, or lack of self-service tooling โ€” not the pipeline itself.

A team that has to wait three days for an ops engineer to provision a dev environment will never ship fast, no matter how optimized their Dockerfile is. A team that can provision their own environment in five minutes โ€” with security, compliance, and cost guardrails already baked in โ€” will ship fast almost regardless of their pipeline speed.

๐Ÿš€ The goal of self-service DevOps: Make the right thing easy and the wrong thing hard. Not through process โ€” through product. Build the platform your developers deserve.

Getting Started: The Practical Path

If you're building self-service infrastructure from scratch, start here:

  1. Standardize your IaC modules โ€” Create reusable, opinionated Terraform or Pulumi modules for your most common patterns (VMs, databases, queues). Give developers sensible defaults they can override.
  2. Automate your most common requests โ€” What do developers ask ops for most often? Start there. Automate the top three requests and you'll eliminate 80% of your ticket queue.
  3. Build a thin service catalog โ€” Even a simple README listing available services and how to use them is a starting point. Backstage can come later.
  4. Instrument everything โ€” Self-service only works if developers can see what's happening. Expose dashboards, logs, and alerts to the teams that own each service.
  5. Treat your platform as a product โ€” Get feedback from your internal users. Prioritize their pain points. Ship improvements. Repeat.
Platform Engineering DevOps GitOps IaC Self-Service AI Agents

๐Ÿ‘จโ€๐Ÿ’ป
Mayur Rele
Senior Director, IT & Information Security ยท Parachute Health

15+ years in DevOps, cloud infrastructure, and cybersecurity. 700+ research citations. Scientist of the Year 2024. Writing about what actually works.

โ† Back to all posts