DevOps transformed how software organizations build and ship code. But after a decade of DevOps adoption, many engineering teams are drowning in operational complexity. Developers are expected to write application code, configure CI/CD pipelines, manage Kubernetes manifests, handle monitoring and alerting, and understand cloud infrastructure — all while shipping features faster than ever. The promise of DevOps was developer empowerment; the reality, for many teams, has been developer overload.
Platform engineering has emerged as the answer to this challenge. Instead of expecting every developer to be a full-stack infrastructure expert, platform engineering teams build Internal Developer Platforms (IDPs) that provide self-service access to the tools and infrastructure developers need, while abstracting away the underlying complexity.
At StrikingWeb, we have been building internal developer platforms for clients since 2023, and we have seen firsthand how this approach transforms engineering productivity. Here is what you need to know about platform engineering in 2024.
The Problem Platform Engineering Solves
Traditional DevOps culture aimed to break down silos between development and operations. The idea was beautiful: developers who understand operations make better decisions, and operations teams who understand development build better infrastructure. In practice, however, this created a new problem — cognitive overload.
Consider what a typical developer at a mid-sized company must deal with today:
- Write application code in one or more languages
- Configure Dockerfiles and container builds
- Write and maintain Kubernetes manifests or Helm charts
- Set up and manage CI/CD pipelines
- Configure monitoring, logging, and alerting
- Manage database migrations and connections
- Handle secrets and configuration management
- Understand networking, load balancing, and DNS
- Comply with security policies and governance requirements
This is too much. Research from Puppet's State of DevOps reports consistently shows that the most productive engineering organizations have invested in developer self-service platforms that handle infrastructure concerns, allowing developers to focus on what they do best — building application logic.
What Is an Internal Developer Platform?
An Internal Developer Platform (IDP) is a layer of tools, workflows, and self-service capabilities that sits between developers and the underlying infrastructure. It is not a single product — it is a curated set of tools and abstractions tailored to your organization's specific needs.
A well-designed IDP typically includes:
Service Catalog
A central registry of all services, their owners, documentation, APIs, dependencies, and health status. Developers can discover existing services, understand how they fit together, and avoid duplicating work. Backstage, Spotify's open-source developer portal, has become the de facto standard for building service catalogs.
Golden Paths
Pre-configured, opinionated templates for common tasks. A golden path for creating a new microservice might include a project scaffold with the company's standard directory structure, a pre-configured CI/CD pipeline, Kubernetes deployment manifests, monitoring dashboards, and alert rules — all generated from a single command or web form.
"Golden paths are not about restricting developer freedom — they are about removing the friction from doing things the right way."
Self-Service Infrastructure
Developers can provision databases, message queues, caches, and other infrastructure resources through a self-service portal or CLI, without filing tickets with an operations team. The platform handles provisioning, configuration, access management, and compliance automatically.
Environment Management
Spinning up development, staging, and preview environments on demand, with production-like configurations. Modern IDPs can create ephemeral environments for every pull request, allowing developers to test changes in isolation before merging.
Observability Layer
Standardized monitoring, logging, and tracing that is automatically configured for every service deployed through the platform. Developers get dashboards and alerts out of the box, without configuring Prometheus rules or Grafana panels manually.
Building an IDP: The Technology Stack
Based on our experience building IDPs for clients, here is the technology stack we typically recommend:
Developer Portal: Backstage
Backstage provides the frontend for your IDP — the service catalog, documentation hub, and template engine. Its plugin architecture allows you to integrate virtually any tool, from CI/CD platforms to cloud providers to custom internal systems. We have deployed Backstage with custom plugins for AWS resource provisioning, Jira integration, and automated security scanning.
Infrastructure Orchestration: Crossplane or Terraform
Crossplane extends Kubernetes with custom resource definitions for cloud infrastructure, allowing developers to provision AWS RDS databases, S3 buckets, or Azure services using familiar Kubernetes manifests. Terraform, orchestrated through platforms like Atlantis or Spacelift, remains a strong choice for teams that prefer its mature ecosystem and provider coverage.
GitOps: ArgoCD or Flux
GitOps ensures that the desired state of your infrastructure and applications is declared in Git, and a reconciliation controller continuously ensures the actual state matches. ArgoCD has emerged as the most popular choice, with its intuitive web UI and robust sync capabilities.
CI/CD: GitHub Actions or GitLab CI
Most organizations already have CI/CD in place. The platform engineering team's job is not to replace it but to standardize it — providing reusable workflow templates, shared actions, and consistent build processes that developers can adopt with minimal effort.
Observability: Grafana Stack
The Grafana ecosystem (Grafana for dashboards, Loki for logs, Tempo for traces, Mimir for metrics) provides a unified observability platform that can be automatically provisioned for every service. OpenTelemetry standardizes the instrumentation layer across languages and frameworks.
The Platform Team: Structure and Mindset
A critical distinction between platform engineering and traditional infrastructure teams is the product mindset. The platform team treats developers as their customers. They conduct user research, prioritize features based on developer feedback, measure adoption and satisfaction, and iterate on the platform continuously.
Successful platform teams we have worked with share several characteristics:
- Small and focused: Start with 2 to 4 engineers who deeply understand both infrastructure and developer experience
- Product-oriented: They have a product manager (or act as their own), track adoption metrics, and prioritize based on developer impact
- Empathetic: They sit with application developers regularly, understand their pain points firsthand, and design solutions around actual workflows
- Opinionated but flexible: They establish strong defaults (golden paths) while allowing teams with specialized needs to customize
Measuring Platform Success
How do you know your platform engineering investment is paying off? We recommend tracking these metrics:
- Time to first deployment: How long does it take a new developer to ship their first change to production? Effective IDPs reduce this from weeks to hours.
- Lead time for changes: The time from code commit to production deployment. This is one of the four DORA metrics and directly reflects delivery efficiency.
- Developer satisfaction (NPS): Survey developers regularly. If they love the platform, they will use it. If they hate it, they will route around it.
- Platform adoption rate: What percentage of teams and services use the platform? Voluntary adoption is the ultimate validation.
- Cognitive load reduction: Track the number of distinct tools and systems a developer needs to interact with. A good platform reduces this over time.
Common Pitfalls
- Building in isolation: Platform teams that build what they think developers need, rather than what developers actually need, create unused tools. Talk to your users constantly.
- Over-abstracting: Hiding too much complexity can be as problematic as exposing too much. Developers need to understand enough about the underlying infrastructure to debug issues and make informed decisions.
- Not treating it as a product: Platforms that launch once and are not iterated on become legacy systems. Continuous improvement is essential.
- Mandating adoption: The best platforms win through superior developer experience, not management mandates. If you have to force developers to use your platform, the platform is not good enough.
Getting Started
If you are considering platform engineering for your organization, start small. Identify the biggest friction points in your developer experience — is it environment provisioning? CI/CD configuration? Monitoring setup? — and build a self-service solution for that one pain point. Measure adoption and impact, iterate, and expand from there.
At StrikingWeb, our Cloud and DevOps practice includes platform engineering engagements where we help organizations design, build, and operate internal developer platforms that measurably improve engineering productivity. Whether you are starting from scratch or evolving an existing DevOps practice, we can help you build the right platform for your team.