The Rise of Platform Engineering

Modern cloud systems have a lot of moving parts. A single service might need a container image, a Kubernetes deployment, a database, secrets, DNS, TLS certificates, a CI pipeline, dashboards, alerts and a sensible set of IAM permissions. Expecting every product developer to be an expert in all of that is unrealistic, and when each team works it out alone, you end up with twenty slightly different ways of doing the same thing.

Platform engineering is the response to that problem. Instead of asking every developer to become a part-time infrastructure specialist, a platform team builds a set of shared, self-service tools and paved routes that make the right way the easy way. This guide explains what platform engineering is, how it relates to DevOps and SRE, which tools are common, what platform engineers actually do, and how you can build a tiny "golden path" of your own to learn the ideas properly.

What platform engineering is

Platform engineering is the discipline of designing and running an internal developer platform (IDP): a curated set of tools, templates, automation and documentation that lets product teams build, deploy and operate software without needing to understand every layer underneath.

A useful way to think about it: the platform sits between the raw infrastructure (cloud accounts, Kubernetes clusters, networks) and the application teams. It hides the parts developers do not need to care about and exposes the parts they do, through a simple interface such as a portal, a CLI, a Git repository template or a pull request.

An internal developer platform is not one product you buy. It is usually a combination of existing tools glued together with conventions and automation. A small company's platform might be a template repository, a reusable GitHub Actions workflow and a Terraform module. A larger organisation's platform might include a developer portal, a service catalogue, a Kubernetes control plane for infrastructure, GitOps delivery and built-in observability.

Golden paths

A golden path (sometimes called a paved road) is the supported, opinionated way to do a common task, such as "create a new web service" or "add a Postgres database". It comes with sensible defaults already in place: CI, security scanning, logging, health checks, resource limits and a deployment pipeline.

The key word is supported, not mandatory. Teams can step off the golden path when they have a good reason, but then they take on more of the responsibility themselves. A good golden path is attractive because it saves time, not because people are forced onto it.

Self-service

Self-service means a developer can get what they need without opening a ticket and waiting for another team. Instead of "please create me a database" sitting in a queue for days, the developer fills in a template, opens a pull request or clicks a button, and the platform provisions the resource with the organisation's standards already applied.

Self-service does not mean "anything goes". Guardrails such as policy checks, approved instance sizes, tagging rules and cost limits are built in, so speed does not come at the expense of security.

Platform as a product

The most important idea in platform engineering is treating the platform as a product, with developers as its customers. That means:

• Talking to developers to find their real pain points before building anything.
• Starting small and shipping improvements in iterations.
• Writing clear documentation and examples.
• Measuring whether people actually use the platform and whether it makes their work faster.
• Deprecating features carefully, with migration paths, rather than breaking teams.

Platforms built without this mindset often become a collection of tools nobody asked for. Platforms built with it become something teams genuinely prefer to use.

Why teams are adopting it

The reasons are practical rather than fashionable:

1. Reducing cognitive load. Developers should spend most of their time on business logic, not on debugging ingress controllers or writing Terraform from scratch.
2. Consistency at scale. When every service is created from the same template, security settings, logging and monitoring are there by default rather than remembered by some teams and forgotten by others.
3. Faster onboarding. A new engineer can ship a service in their first week if the golden path is well documented.
4. Fewer tickets and bottlenecks. Operations teams stop being the gatekeepers for every small request.
5. Better governance. Policies are enforced in code and pipelines, so audits become easier and drift becomes rarer.

None of this is free. A platform needs a team to build and maintain it, and a badly designed one adds friction rather than removing it. For a company with three developers and one application, a full IDP is usually overkill. The value grows as the number of teams and services grows.

Platform engineering, DevOps and SRE

Platform engineering does not replace DevOps. DevOps is a culture and set of practices about developers and operations sharing responsibility for delivering and running software. Platform engineering is one way of putting that culture into practice at scale: instead of every team building its own pipelines and infrastructure, a dedicated team builds shared capabilities that make "you build it, you run it" realistic.

SRE (site reliability engineering) focuses on reliability: service level objectives, error budgets, incident response and reducing toil. Platform teams and SRE teams often work closely, and in smaller organisations they may be the same people. If you want a deeper comparison of the first two, read our article on SRE vs DevOps.

In practice the boundaries are blurry, and job titles vary a lot between companies. The underlying skills overlap heavily, which is good news if you are learning: time spent on one is rarely wasted on the others.

Common tools in a platform

There is no single correct stack. These are tools you will see often, and what each one contributes.

Backstage is an open source framework for building developer portals. Its software templates can create a new repository from a skeleton, fill in names and settings, and register the service in a catalogue. It is powerful but needs real engineering effort to run and customise, so do not start with it unless you have a clear need.

Crossplane extends Kubernetes so that cloud resources (buckets, databases, networks) can be described as Kubernetes objects. Platform teams define higher-level "compositions" so a developer can request something like a PostgresInstance without seeing every cloud setting underneath. It pairs naturally with Argo CD, which watches a Git repository and applies changes to the cluster. You can see how these fit together in our visual explainers on Crossplane with Argo CD and GitOps architecture.

Terraform remains the most common way to manage infrastructure as code. In a platform, the value is in well-designed modules with safe defaults, so teams compose infrastructure rather than writing it from nothing. If you are new to it, start with Terraform for beginners.

What a platform engineer does day to day

The work varies, but a typical week might include:

• Improving a service template after developers report that the default health check does not suit their framework.
• Writing or reviewing a Terraform module for a new type of resource, such as a message queue.
• Upgrading Kubernetes clusters and checking that platform components still work.
• Maintaining shared CI workflows and fixing a pipeline that broke after a dependency update.
• Adding a policy check, for example rejecting containers that run as root or resources without cost tags.
• Pairing with a product team to migrate an older service onto the golden path.
• Writing documentation and answering questions in the team's support channel.
• Looking at usage and feedback to decide what to build next.

Notice how much of this is communication. Platform engineers spend a surprising amount of time listening to developers, writing docs and explaining trade-offs. Strong technical skills matter, but so does empathy for the people using what you build.

Skills you need

Most platform engineers come from DevOps, SRE, backend development or systems administration. The core skills are:

• Linux and networking fundamentals. Processes, permissions, DNS, HTTP, TLS, load balancing.
• Git and code review. Everything in a platform lives in Git.
• A programming or scripting language. Bash plus one of Python or Go is a strong combination.
• Containers and Kubernetes. Deployments, services, ingress, config, RBAC and troubleshooting. Our Kubernetes for beginners guide is a good start.
• Infrastructure as code. Terraform modules, state, plans and reviews.
• CI/CD. Building pipelines and reusable workflows. See our GitHub Actions CI/CD guide.
• At least one cloud provider. AWS, Azure or GCP, including IAM.
• Observability. Metrics, logs and traces, and how to make them default.
• Product thinking and writing. Gathering requirements, prioritising and documenting clearly.

You do not need all of these on day one. Platform engineering is rarely an entry-level title; most people reach it after a period in a DevOps, cloud or SRE role. That is a reason to build a strong foundation, not a reason to wait.

Mini project: build a tiny golden path

The best way to understand platform engineering is to build a small platform for yourself. This project creates a template repository that any "developer" (you, for now) can use to create a new service that is built, tested and deployed to Kubernetes in a consistent way.

You will need a GitHub account, Docker, kubectl, kind (Kubernetes in Docker) and Terraform installed locally.

Step 1: Create a local cluster

kind create cluster --name platform-lab
kubectl cluster-info --context kind-platform-lab
kubectl get nodes

This is your "production" for the exercise. In a real platform it would be a managed cluster such as EKS, AKS or GKE.

Step 2: Create the template repository

Create a new GitHub repository called service-template and tick Template repository in its settings. Give it this structure:

service-template/
  app/
    main.py
    requirements.txt
  Dockerfile
  deploy/
    main.tf
    variables.tf
  .github/workflows/ci.yml
  README.md

A minimal application with a health endpoint:

# app/main.py
from flask import Flask, jsonify

app = Flask(__name__)

@app.get("/healthz")
def health():
    return jsonify(status="ok")

@app.get("/")
def index():
    return jsonify(message="Hello from the golden path")

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

# app/requirements.txt
flask==3.0.3

A Dockerfile with sensible defaults, including a non-root user:

FROM python:3.12-slim
WORKDIR /app
COPY app/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ .
RUN useradd --uid 10001 appuser
USER 10001
EXPOSE 8080
CMD ["python", "main.py"]

The defaults here are the point. Every service created from this template runs as a non-root user and exposes a health check, without the developer having to remember either.

Step 3: Add a shared CI pipeline

This workflow builds the image and pushes it to GitHub Container Registry on every push to main:

# .github/workflows/ci.yml
name: ci
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: ${{ github.event_name == 'push' }}
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

Once you have more than one service, move the job into a separate repository as a reusable workflow (using on: workflow_call) and have each service call it. Then a fix to the pipeline reaches every team at once. That is a platform capability in miniature.

Step 4: Deploy with Terraform

Use the Terraform Kubernetes provider to describe the deployment. Developers only set a couple of variables; the platform decides the rest.

# deploy/variables.tf
variable "service_name" {
  type = string
}

variable "image" {
  type = string
}

variable "replicas" {
  type    = number
  default = 2
}

# deploy/main.tf
terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.31"
    }
  }
}

provider "kubernetes" {
  config_path    = "~/.kube/config"
  config_context = "kind-platform-lab"
}

resource "kubernetes_namespace" "svc" {
  metadata {
    name   = var.service_name
    labels = { "managed-by" = "platform" }
  }
}

resource "kubernetes_deployment" "svc" {
  metadata {
    name      = var.service_name
    namespace = kubernetes_namespace.svc.metadata[0].name
  }
  spec {
    replicas = var.replicas
    selector { match_labels = { app = var.service_name } }
    template {
      metadata { labels = { app = var.service_name } }
      spec {
        container {
          name  = var.service_name
          image = var.image
          port { container_port = 8080 }
          resources {
            requests = { cpu = "50m", memory = "64Mi" }
            limits   = { cpu = "250m", memory = "128Mi" }
          }
          liveness_probe {
            http_get {
              path = "/healthz"
              port = 8080
            }
          }
        }
      }
    }
  }
}

resource "kubernetes_service" "svc" {
  metadata {
    name      = var.service_name
    namespace = kubernetes_namespace.svc.metadata[0].name
  }
  spec {
    selector = { app = var.service_name }
    port {
      port        = 80
      target_port = 8080
    }
  }
}

If your package on GHCR is private, either make it public for this exercise or create an image pull secret in the namespace.

Step 5: Use the golden path

Now act as a developer. Click Use this template on GitHub to create a repository called orders-api, push a commit, and wait for CI to publish the image. Then deploy:

cd deploy
terraform init
terraform apply \
  -var="service_name=orders-api" \
  -var="image=ghcr.io/<your-user>/orders-api:<commit-sha>"

kubectl -n orders-api get pods
kubectl -n orders-api port-forward svc/orders-api 8080:80
curl http://localhost:8080/healthz

You have just created a new service with CI, a hardened container, resource limits, a health check and a repeatable deployment, by filling in two values. That is the essence of a golden path.

Step 6: Stretch goals

Once the basics work, extend it in the same direction a real platform would:

• Turn deploy/ into a versioned Terraform module in its own repository.
• Replace terraform apply from your laptop with Argo CD watching a manifests repository.
• Add a policy check in CI, for example scanning the image with Trivy.
• Write a Backstage software template that creates the repository for you.
• Write a one-page "how to create a service" document and ask a friend to follow it without help. Wherever they get stuck is your next improvement.

If you want to practise the Kubernetes and Terraform parts in a game-like setting first, try K8s Commander and Terraform Arena.

Common mistakes

Building a portal first. A shiny portal on top of inconsistent pipelines does not help anyone. Get the templates, modules and pipelines right, then add a portal if people need one.

Not talking to developers. If the platform team decides what developers need without asking them, adoption will be low. Interview teams, watch them work and fix the most painful problems first.

Forcing everyone onto the platform. Mandates breed workarounds. Make the golden path so convenient that teams choose it.

Abstracting too much. Hiding everything can leave developers stuck when something breaks. Expose logs, metrics and enough detail to debug, and document what happens underneath.

Too many tools. Each tool adds upgrades, security patches and knowledge to maintain. Adopt new tools only when they solve a real problem the current stack cannot.

Treating the platform as a one-off project. A platform needs ongoing maintenance, versioning, support and a roadmap. Without that it decays quickly.

Ignoring documentation. An undocumented golden path is just someone else's private setup.

A realistic learning plan

Platform engineering builds on DevOps fundamentals, so the plan below starts there. The timings assume around eight to ten hours a week alongside work or study; adjust to your own pace.

Months 1-2: Foundations. Linux command line, Bash scripting, Git and GitHub, networking basics (DNS, HTTP, TLS), and one programming language to a comfortable level.

Months 3-4: Cloud and containers. One cloud provider's core services and IAM, Docker images and registries, and your first CI pipeline with GitHub Actions.

Months 5-6: Kubernetes and infrastructure as code. Deployments, services, ingress, config and troubleshooting, plus Terraform including modules and remote state. Our Kubernetes playground lets you practise without setting up a cluster.

Months 7-8: Platform patterns. GitOps with Argo CD, reusable workflows, policy checks, observability basics, and the mini project above extended with the stretch goals.

Months 9 onwards: Portfolio and job search. Polish two or three projects with clear READMEs, write about what you built, and apply for junior DevOps, cloud or SRE roles. Platform roles usually follow after some production experience. Our guide on becoming a DevOps engineer in Nigeria covers the job search side in more detail.

If you prefer structured learning with mentorship and feedback on your projects, have a look at our courses, including the DevOps Deep Dive.

FAQ

Is platform engineering replacing DevOps? No. It is a way of applying DevOps principles at scale. Many platform engineers previously held DevOps titles, and the skills overlap heavily.

Do I need to learn Backstage to become a platform engineer? Not at first. It is useful to know, but many platforms work well without a portal. Focus on Kubernetes, Terraform, CI/CD and a cloud provider before adding Backstage.

Can a beginner go straight into a platform engineering role? It is uncommon. Most people start in a junior DevOps, cloud, SRE or backend role and move into platform work once they understand how software is built and run in production.

Does a small company need an internal developer platform? Usually not a formal one. But even a small team benefits from a template repository, a shared pipeline and a few well-written Terraform modules. That is a platform, just a small one.

Which should I learn first, Crossplane or Terraform? Terraform. It is more widely used and teaches infrastructure as code concepts that transfer to Crossplane later.

Get guidance on your next step

Platform engineering is a natural destination for people who enjoy both infrastructure and helping other engineers work better. If you are not sure where you are on that journey, or which skills to focus on next, book a free consultation with our team. We will look at your background and goals and help you plan a realistic route into cloud, DevOps and platform work.