“I need a new environment.” That used to mean a ticket, two weeks of waiting, and a frustrated developer. Today it means a click in the portal and within 10 minutes they have a running Kubernetes namespace with a database, monitoring, and CI/CD pipeline. This is what our internal developer platform looks like — and here’s how we built it.
Why Platform Engineering¶
With 30+ microservices and 5 development teams, we hit a scaling problem. Not technical — organizational. Every team handled deployment differently. Infrastructure knowledge was concentrated in 2 people. Onboarding a new developer took a week just to set up the environment.
Platform engineering = a dedicated team builds an internal platform that abstracts away infrastructure complexity. Developers focus on business logic; the platform handles deployment, monitoring, scaling, and security.
Golden Paths — Not a Golden Cage¶
A golden path = the recommended way to do things. Need a new service? Here’s a template (Spring Boot + Dockerfile + Helm chart + CI pipeline). Need a database? Here’s a provisioner (PostgreSQL on Kubernetes with backup).
The key: golden paths are recommendations, not mandates. A team can go off the path, but then they handle infrastructure on their own. 95% of teams stay on the golden path because it’s easier.
Backstage — Developer Portal¶
Spotify’s Backstage as a self-service portal. A catalog of all services (ownership, dependencies, API docs, runbooks). Templates for creating new services (cookiecutter + Backstage scaffolder). Integration with Kubernetes, ArgoCD, Grafana, PagerDuty.
A developer sees in one place: their services, their health, deployment history, metrics, open incidents. No switching between 10 tools.
Self-Service Infrastructure¶
Crossplane for infrastructure provisioning via Kubernetes CRDs. A developer creates a YAML manifest — “I want a PostgreSQL database, 10 GB, in the staging namespace” → Crossplane provisions Azure Database for PostgreSQL → the connection string appears in a Kubernetes Secret.
The same approach for Redis, Kafka topics, and Azure Blob containers. The infra team defines the “offering” (what’s available and with what parameters); developers consume it via self-service.
CI/CD Standardization¶
Shared GitHub Actions workflows. Every service has a .github/workflows/ci.yml that calls a reusable workflow from the platform-workflows repository. Build, test, scan (Trivy), push image, deploy via ArgoCD — standard for all services. Custom steps via extensible hooks.
Measuring Developer Experience¶
DORA metrics + developer satisfaction survey (quarterly):
- Time to first deployment (new service): from 5 days to 2 hours
- New developer onboarding: from 5 days to 1 day
- Cognitive load score (survey): from 7.2 to 4.1 (out of 10)
- Developer satisfaction: from 3.2 to 4.1 (out of 5)
Lessons Learned¶
The platform is a product. It has customers (developers), a product owner, a roadmap, and a feedback loop. Build it as a product, not a project.
Start small. Don’t build the entire platform at once. Start with what hurts the most (for us: environment provisioning).
Documentation > automation. Sometimes a good runbook is enough instead of full automation. Automate once the process is stable.
The Platform as a Multiplier¶
Platform engineering isn’t overhead — it’s an investment in the speed of the entire organization. 3 people on the platform team accelerate 30 developers. That’s a multiplier that pays off.
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us