Building a Cloud-Native Container Platform from Scratch - Part 5

By now, your platform has all the infrastructure essentials: a secure Kubernetes foundation, GitOps-based delivery, ingress, observability, and secrets management. But to truly empower developers — and reduce cognitive load — we need to build something more than infrastructure.

We need a developer experience (DevEx) layer.

In this part, we’ll walk through how to provide self-service capabilities that abstract away Kubernetes complexity and make the platform usable by product teams.

Full series

1. Part 1: Why Build a Self-Service Container Platform
2. Part 2: Choosing Your Platform’s Building Blocks
3. Part 3: Bootstrapping Your Infrastructure with Terraform
4. Part 4: Installing Core Platform Services
5. Part 5: Crafting the Developer Experience Layer (you are here)
6. Part 6: Scaling the Platform — Multi-Tenancy, Environments, and Governance
7. Part 7: Day-2 Operations and Platform Maturity
8. Part 8: The Future of Your Internal Platform

What Developers Really Want

Ask most product engineers how they want to deploy services, and you won’t hear “Helm values” or “pod specs.” They want:

• A place to push code
• A repeatable CI/CD pipeline
• A clear way to request infrastructure (databases, secrets, DNS)
• Logs, metrics, and health checks at their fingertips

So our goal is to build opinionated golden paths while still keeping things modular and flexible.

Step 1: Namespace-as-a-Service

Start by creating an automated way for teams to request and manage their own isolated namespaces, complete with:

• Pre-provisioned RBAC (read/write for devs, read-only for others)
• Resource quotas and network policies
• Tooling: metrics dashboards, secrets access, CI/CD integration

This can be automated using GitOps (Argo CD) or a portal where teams submit a request and get a PR in the platform config repo.

Here’s a typical structure in Git:

namespaces/
  team-a/
    namespace.yaml
    rbac.yaml
    resource-quota.yaml
    application.yaml

Step 2: Standardised Workload Templates

Not every team wants to figure out how to configure liveness probes, memory requests, or TLS.

Give them curated templates, delivered as:

• Helm charts (internal chart repo)
• Kustomize bases
• Platform-wide ApplicationSet definitions in Argo CD

Each template might include:

• A deployment with sane defaults
• Autoscaling enabled
• TLS and ingress pre-configured
• Service monitors for Prometheus
• External secret references

Then teams just need to tweak a few inputs (repo URL, image tag, port).

Step 3: CI/CD Integration

CI/CD should be plug-and-play. Use tools like:

• GitHub Actions, GitLab CI, or Tekton to build and push images
• Argo CD to deploy from Git branches or tags
• Optional integration with Backstage for a one-click “Create Component” flow

Tip: Define a reusable CI template that teams can extend with their own tests:

jobs:
  build:
    steps:
      - uses: actions/checkout@v3
      - name: Build & Push
        run: |
          docker build -t $REGISTRY/$SERVICE:$SHA .
          docker push $REGISTRY/$SERVICE:$SHA

Step 4: Internal Developer Portal (Optional, but Powerful)

To tie it all together, consider exposing this experience through a developer portal, like Backstage.

Features include:

• Templates for new services (with built-in CI/CD, observability, secrets)
• One-click deploys to dev or staging
• Service catalog with docs, APIs, ownership
• Direct links to logs, metrics, and alerts

The portal becomes the front door to your platform; giving developers confidence and autonomy.

What You’ve Achieved

At this point, you’ve shifted from “a Kubernetes cluster” to a true internal platform. Developers can:

• Get a namespace with built-in guardrails
• Deploy services using templated, approved paths
• Push code and see it deployed automatically
• Access logs, metrics, and alerts without digging through YAML

All while your platform team maintains central governance, security, and consistency.

Coming Up in Part 6

In the next part, we’ll zoom out and talk about multi-tenancy, environment management, and scaling your platform for teams and regions.

Part 6: Scaling the Platform — Multi-Tenancy, Environments, and Governance