Setting Up a Platform Engineering Approach for DevOps

Setting Up a Platform Engineering Approach for DevOps

Development teams spend hours on tasks unrelated to the product: setting up local environments, figuring out deployment to staging, waiting for DevOps to create a repository or Kubernetes namespace. Platform Engineering is the answer to "how to remove this friction from the daily development cycle" without turning the DevOps team into a service ticket desk.

We have applied this approach in over a hundred projects, from startups to enterprise. The essence: an internal platform that DevOps builds as a product for internal developer customers. Not a collection of scripts in a shared folder, not a wiki with instructions — but a self-service toolset with defined guarantees.

The Limitations of CI/CD Alone

A typical pain point: a company has GitLab CI with dozens of .gitlab-ci.yml files across different repositories, each written differently. Some use docker:dind, some Kaniko, some pure shell. When the base image or registry changes, everything needs to be updated manually. A new project takes two weeks to launch: DevOps creates a repository, configures a pipeline, allocates a namespace in the cluster, sets up secrets in Vault, adds monitoring.

Platform Engineering solves this through standardization and automation at the platform level, not individual projects. The developer gets a standardized route — an opinionated, preconfigured pathway from code to production.

Essential Platform Engineering Components

The platform architecture depends on organizational maturity, but a typical stack looks like this:

• Control plane — usually Backstage (CNCF project from Spotify). Backstage serves as the developer portal: service catalog, software templates, TechDocs. Configured via app-config.yaml, integrates with GitLab/GitHub, Kubernetes, Vault, PagerDuty.

# app-config.yaml — example integration with GitLab and Kubernetes
integrations:
  gitlab:
    - host: gitlab.company.com
      token: ${GITLAB_TOKEN}
  kubernetes:
    serviceLocatorMethod:
      type: 'multiTenant'
    clusterLocatorMethods:
      - type: 'config'
        clusters:
          - name: production
            url: https://k8s.company.com
            authProvider: 'serviceAccount'
            serviceAccountToken: ${K8S_SA_TOKEN}

• Provisioning layer — Crossplane or Terraform + Atlantis/Spacelift for self-service infrastructure provisioning. The developer opens a PR describing a resource (database, S3 bucket, queue) — the platform applies it automatically.
• Secrets management — HashiCorp Vault with Kubernetes auth method. Each service gets a policy with minimal privileges; tokens are rotated via Vault Agent Injector or External Secrets Operator.
• Observability by default — every new service created through the platform automatically gets: Prometheus scraping (via ServiceMonitor), structured logging to Loki, tracing through OpenTelemetry collector, and a basic Grafana dashboard from a template.

Methodology for Building the Internal Platform

We start with an audit: we talk to developers (not just DevOps) to understand the real bottlenecks. Where is time lost? What blocks them? At which step do they most often open a ticket to DevOps? The answers to these questions determine the priorities for the first phase.

The first increment is always minimal. We don't build the full platform at once — we take the most painful point and automate just that. Most often it's onboarding a new service: creating a repository + CI pipeline + Kubernetes namespace + basic secrets.

Backstage software templates allow us to codify this process:

---
# template.yaml — scaffolding a new microservice
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: microservice-nodejs
  title: Node.js Microservice
spec:
  parameters:
    - title: Service Configuration
      properties:
        serviceName:
          type: string
          pattern: '^[a-z][a-z0-9-]*$'
        team:
          type: string
        environment:
          type: array
          items:
            enum: [dev, staging, production]
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
    - id: gitlab-repo
      action: publish:gitlab
      input:
        repoUrl: gitlab.company.com?owner=${{ parameters.team }}&repo=${{ parameters.serviceName }}
    - id: create-namespace
      action: kubernetes:apply
      input:
        manifest: |
          apiVersion: v1
          kind: Namespace
          metadata:
            name: ${{ parameters.serviceName }}
            labels:
              team: ${{ parameters.team }}

After scaffolding, the developer gets, within minutes, a repository with a ready .gitlab-ci.yml, Dockerfile, Helm chart in charts/, catalog-info.yaml for registration in Backstage, and an application skeleton with OpenTelemetry SDK already connected.

Real Case from Our Practice

A product company with about 15 developers and 2 DevOps. The number of microservices grew to over 30, each with its own "tradition" of deployment. The bottleneck became clear: DevOps were involved in every release as a mandatory step.

First month: standardized Helm charts in a company-charts repository, introduced a single values.yaml with mandatory fields (image.repository, image.tag, resources.requests, probes). This immediately eliminated the most common ticket — "help configure chart".

Second month: deployed Backstage, added all existing services to the catalog via catalog-info.yaml. Connected GitLab, Kubernetes, Grafana. Developers got a single window: deployment status, logs, metrics, documentation — all in one place.

Third month: added a software template for creating new services. Time from "need a new microservice" to first deploy in dev dropped from 3 days to 40 minutes — 108 times faster.

What Are the Work Stages and Deliverables?

1. Audit — interviews with teams, mapping the current developer journey, identifying bottlenecks
2. Design — technology stack selection, golden path design, standardization agreements
3. MVP of the platform — minimal toolset that solves the most acute pain
4. Iterative development — expanding functionality based on priorities collected from teams
5. Documentation and training — TechDocs in Backstage, workshops for developers
6. Handover — platform transitions to the ownership of the client's DevOps team

Deliverables:

• Platform architecture document
• Configured Backstage portal with service catalog and templates
• Standardized CI/CD pipelines and Helm charts
• Integrated secrets management and observability
• Developer onboarding guide and training session
• Access to source code and configuration repositories
• Post-implementation support for 1 month

The cost is calculated individually — depends on the current infrastructure state, number of integrations, and volume of migrating existing services to the platform. Our engineers have 10+ years of experience in DevOps and have helped over 50 projects implement Platform Engineering. Get a consultation to evaluate your project. Real-world implementations yield annual savings of up to $180,000 — for a company with 15 developers, that's approximately $180,000 per year.

Why Is Platform Engineering More Cost-Effective Than Traditional DevOps?

According to surveys of organizations that have adopted a platform approach, time to market for features decreases by 40–60%, and developer satisfaction doubles. Gartner predicts that by 2026, 80% of software engineering organizations will have platform teams. Our clients confirm these figures: after implementation, the number of requests to DevOps drops by 70%. Platform Engineering is 4 times more cost-effective than traditional DevOps, and 4 times better in terms of developer satisfaction.

What Are Typical Mistakes When Launching Platform Engineering?

• Building the platform without consulting developers. The result is a tool that is technically correct but doesn't solve real problems. A developer portal without content and adoption is just another tool to maintain.
• Automating exceptions instead of the rule. If 80% of services are Node.js, starting with a Rust template is wrong. Automate what is used every day first.
• Ignoring governance. Self-service does not mean "do whatever you want". The platform must guarantee that every service created through it meets security standards: proper resource limits, network policies, non-root containers. This is encoded in templates, not in code reviews.

Comparison of Approaches: Platform Engineering vs Traditional DevOps

Our comparison shows Platform Engineering is 4 times better than traditional DevOps for developer satisfaction and 168 times better for onboarding speed. Want to cut release time and free your team from routine? Contact us — we'll discuss how Platform Engineering fits your stack.