Platform Engineering, IDPs & GitOps

Raw Kubernetes is a construction kit, not a product

Give 40 product teams a bare cluster and each one reinvents CI, deployment YAML, secrets wiring, ingress, dashboards, and on-call, badly and differently. That cognitive load is the tax that kills velocity. Platform engineering treats the internal developer experience as a product: a small platform team builds paved roads so the median engineer never touches the messy layers.

The Internal Developer Platform

An IDP is the interface over that machinery. Over raw Kubernetes it adds three things a product team actually wants: self-service golden paths (scaffold a new service from a template, deploy it, and get logs/metrics/traces wired up with one command or one portal click), abstraction (the developer declares "I need a service with a Postgres and a queue," and the platform materializes the Terraform, Helm, and RBAC), and guardrails so the paved road is also the compliant road. The classic reference is Spotify's Backstage: a service catalog that answers who owns this, what depends on it, is it meeting its scorecard (has a runbook, passing security scan, defined SLO), plus software templates for scaffolding.

GitOps

GitOps is the delivery control plane underneath. The principle: Git is the single source of truth for desired state, everything is declarative (Kubernetes manifests, Helm/Kustomize, Terraform), and an in-cluster reconciler (Argo CD or Flux) continuously compares desired state in Git to actual state in the cluster and converges them. You never kubectl apply from a laptop. To ship, you open a pull request that changes the manifest; merge triggers the agent to roll it out.

  developer --> PR to config repo --> merge
                                        |
                          Argo CD / Flux (in cluster)
                                        |  reconcile loop
                          diff(desired in Git, actual)
                                        |
                                   apply / self-heal --> cluster

Why Git as the source of truth: you get an audit log of every prod change (who, what, when, reviewed by whom) for free, rollback is git revert, drift is detected and auto-healed (someone hotfixes the cluster by hand, the reconciler reverts it back to Git), and disaster recovery is "point Argo at the repo and re-sync." Pull-based reconciliation is also more secure than push: no external CI system needs cluster-admin credentials.

Guardrails as code

Instead of a review board that manually approves each deploy, you encode policy: OPA/Gatekeeper or Kyverno admission policies reject a manifest that has no resource limits, runs as root, or pulls an unsigned image. Templates bake in the right defaults. The paved road is faster than going around it, so people stay on it.

Interview nuance: supply-chain security belongs in the platform, not bolted on. Generate an SBOM at build, sign images with cosign, and attach SLSA provenance so the admission controller can verify "this image came from our pipeline, unmodified" before it runs.

Interview nuance: the failure mode to name is the ticket-queue platform team. If shipping still means filing a Jira ticket and waiting two days for the platform team to click deploy, you built a bottleneck, not a platform. Platform-as-product means self-service by default; the team's success metric is adoption and lead time, not tickets closed.

Recap: an IDP is a product that gives teams self-service golden paths (scaffold, deploy, observe) and abstraction over raw Kubernetes; GitOps makes Git the declarative source of truth with an Argo CD/Flux reconciler for audit, rollback, and self-healing; Backstage catalogs ownership and scorecards; guardrails as code (OPA/Kyverno) and supply-chain controls (SBOM, cosign, SLSA) replace gatekeeping; the anti-pattern is a ticket-queue platform team.