Self Serve Infrastructure Principles

Who this is for

Platform Engineers, SREs, and Backend Engineers who design or consume internal developer platforms and want safe, reliable self-service for infrastructure, environments, and deployments.

Prerequisites

• Basic understanding of cloud resources (compute, networking, storage).
• Comfort with infrastructure-as-code (e.g., Terraform) and CI/CD basics.
• Familiarity with Git workflows and environments (dev/stage/prod).

Why this matters

In the Platform Engineer role, you will be asked to:

• Provide a safe, fast way for teams to provision services (apps, databases, queues) without opening tickets.
• Bake in security, compliance, and cost controls automatically.
• Reduce cognitive load on product teams with opinionated defaults and golden paths.
• Measure and improve developer productivity (e.g., fewer blocked tickets, faster lead time).

Concept explained simply

Self-serve infrastructure lets developers request and manage resources on their own—through templates, catalogs, or pipelines—while the platform enforces guardrails. Think of it as a vending machine with safety built in: developers choose items; the platform ensures they get only what is safe, standardized, and auditable.

Mental model

Use the "Railway, not Runway" model:

• Rails: opinionated templates, policies-as-code, quotas, and defaults that keep trains (teams) on track.
• Switches: clear choices for common needs (web app, job, database) with minimal options.
• Signals: visible status, logs, SLOs, and alerts; no hidden work.
• Yard: safe spaces (sandboxes) to experiment with limits and budgets.

Core principles of self-serve infrastructure

1) Product mindset for the platform

Treat the platform as a product with users, feedback loops, SLAs/SLOs, and clear value. Success is measured by adoption, reduced lead time, and developer satisfaction.

2) Golden paths and paved roads

Provide curated templates that encode best practices (security, reliability, cost). Make the default path delightful so few need to go off-road.

3) Abstractions with guardrails, not gates

Expose simple choices and safe defaults; enforce policies automatically. Avoid manual approvals unless risk requires it.

4) Policy as code and compliance by default

Codify rules (e.g., tagging, regions, encryption, size limits). Validate at request time and in CI to prevent drift.

5) Idempotency and immutability

Repeated runs produce the same result; changes are versioned and reviewed. Prefer replace-over-mutate for infra changes where feasible.

6) GitOps and clear change history

Desired state lives in Git; changes flow via PRs and automated controllers. Everything auditable, reversible, and testable.

7) UX matters

Use simple forms, sane defaults, inline validation, and good error messages. Provide instant feedback and progress indicators.

8) Standardization with escape hatches

Standard modules and catalogs reduce variance. Allow controlled overrides for advanced teams with extra checks and visibility.

9) Observability and clear ownership

Every resource should have owners, tags, costs, logs, metrics, and runbooks. Surfaces should show status and who to contact.

10) Security and cost by design

Shift-left scanning, least-privilege RBAC, budget caps, and automatic tagging. Developers should be free to move fast within safe limits.

Worked examples

Example 1: New microservice on a golden path

1. Developer selects "Web service" template.
2. Form asks for service name, team, language, expected traffic tier.
3. Platform generates repo with CI/CD, Dockerfile, IaC module reference, and policies.
   • Defaults: autoscaling min/max, encrypted storage, standardized logging.
4. PR triggers terraform plan with policy checks (tags, region, instance size).
5. Merge deploys to dev; health checks and dashboards auto-provisioned.

Outcome: Service live without tickets; guardrails ensured compliance.

Example 2: Self-serve database with guardrails

1. Developer requests a Postgres instance via catalog.
2. Options constrained by size tiers: small, medium, large; prod-only in approved regions.
3. Policy enforces: encryption at rest, backups enabled, deletion protection for prod.
4. Credentials delivered via secret manager; access scoped to service account.

Outcome: Safe DB provisioning with minimal choices and built-in backups.

Example 3: Safe override with an escape hatch

1. Team needs a larger instance than default tier.
2. They set an override flag and justify risk in PR template.
3. Policy requires review from platform/SecEng for this override only.
4. Decision recorded; dashboards auto-update cost and capacity expectations.

Outcome: Flexibility without normalizing risky defaults.

How to implement (step-by-step)

1. Define top 3–5 golden paths (e.g., web API, async worker, database).
2. Wrap each path in a template + IaC module with opinionated defaults.
3. Add policy-as-code checks that run on PR and at apply time.
4. Expose a simple request UI (forms) or CLI with instant validation feedback.
5. Integrate GitOps: desired state lives in Git, reconciled automatically.
6. Instrument everything: tags, owners, costs, dashboards, SLOs.
7. Collect feedback; iterate on defaults; track adoption and lead time.

Hands-on exercises

Do these to solidify the principles. You can compare with the solutions below.

• Exercise ex1: Design a self-serve flow for a new service request including guardrails and feedback.
• Exercise ex2: Write a short policy-as-code rule that enforces required tags and instance size limits.

Checklist: Did you cover the essentials?

• Clear defaults and minimal choices
• Policy checks before apply
• Owner, tags, cost center captured
• Automated observability and runbooks
• Rollback or delete protection where needed
• Audit trail in Git

Common mistakes and self-check

• Mistake: Too many choices. Self-check: Does the form have more than 7 decisions? Reduce to tiers.
• Mistake: Manual approvals everywhere. Self-check: Can low-risk paths proceed automatically?
• Mistake: Policies only in docs. Self-check: Are rules enforced as code in CI/apply?
• Mistake: Hidden costs. Self-check: Are tags and budgets mandatory and visible?
• Mistake: No owner. Self-check: Is ownership captured and shown on dashboards?
• Mistake: Unclear errors. Self-check: Do users get actionable validation messages?

Practical projects

• Build a "New Service" template that scaffolds repo, CI/CD, IaC module, and monitors.
• Create a catalog item for a database with size tiers, backups, and deletion protection.
• Add policy-as-code to block missing tags, disallowed regions, and oversize instances.
• Publish a one-page runbook for using the platform, including rollback steps.

Learning path

• Start: Self-serve principles (this lesson)
• Next: Templates and golden paths
• Then: Policy as code and GitOps
• Later: Cost and security automation, platform SLOs, developer UX

Mini challenge

In one page, define a new catalog item: inputs, defaults, policies, observability, rollback, and success metrics. Aim for under 7 user decisions.

Next steps

• Do the exercises and compare with solutions.
• Pick one practical project and ship a minimal version this week.
• Take the quick test to check your understanding.

Quick Test

The quick test is available to everyone; only logged-in learners have progress saved.