The Pipeline Problem Nobody Wants to Admit
Ask any engineering leader how their CI/CD works and you will hear a version of the same story. It started simple: a few shell scripts wired into a Jenkins job, maybe a GitHub Actions workflow copied from a blog post. Then a second team joined, copied the scripts, added their own tweaks. Then a third. Now there are forty pipelines, each subtly different, each with its own undocumented assumptions about environment variables, credentials, and deployment targets.
This is not a tooling problem. It is an organisational design problem. And it is exactly what platform engineering exists to solve.
The timing is right to revisit this. Recent discussions in the practitioner community, including self-hosted CI/CD projects like PikoCI and tools like Cordium that aim to eliminate credential injection entirely, signal that developers are actively looking for something better than the status quo. The appetite for lightweight, secure, self-hostable platforms is real. The question is whether to stitch together open-source tools ad hoc or invest in a coherent internal platform.
What Platform Engineering Actually Means
Platform engineering is the discipline of building and operating an internal developer platform (IDP) as a product. The customers are your own engineers. The goal is to reduce cognitive load by giving teams a curated set of capabilities: standardised pipelines, infrastructure templates, observability tooling, and self-service workflows.
The word "product" is deliberate. A platform built like a product has a roadmap, a feedback loop, and someone accountable for its reliability. A platform built as a side project of the infrastructure team has none of those things and usually shows it.
The practical output is a set of golden-path templates: pre-approved, well-tested patterns for deploying a service, provisioning a database, or creating a new environment. Teams can deviate from the golden path, but the path makes the right thing the easy thing.
Ad-Hoc Pipelines vs. a Platform Engineering Approach
The contrast is sharper than most teams expect.
Ad-hoc pipelines look like this:
- Each team owns its own pipeline files
- Credentials are injected manually, often per-pipeline, creating a sprawling secrets surface
- Infrastructure is provisioned by copying Terraform from a colleague's repo
- Onboarding a new service takes days or weeks
- Nobody knows what "production-ready" means, so interpretations vary
A platform engineering approach looks like this:
- Pipelines are instantiated from versioned templates maintained by the platform team
- Credential injection is centralised and audited (projects like Cordium are exploring sandbox-based approaches to eliminate raw credential exposure entirely)
- Infrastructure is provisioned through a self-service catalogue backed by tested IaC modules
- Onboarding a new service takes hours
- "Production-ready" is encoded in the platform: logging, tracing, health checks, and alerting are included by default
The difference is not about which CI/CD tool you use. Teams have built genuine platforms on GitHub Actions, Tekton, and self-hosted systems alike. The tool is less important than the discipline of treating the platform as a product.
Measuring the Difference: DORA Metrics
The DORA research programme (from the DevOps Research and Assessment team, now part of Google) gives us four metrics that reliably predict software delivery performance:
- Deployment frequency: How often does a team deploy to production?
- Lead time for changes: How long does a commit take to reach production?
- Change failure rate: What percentage of deployments cause a production incident?
- Time to restore service: How long does recovery take when something does fail?
Elite-performing organisations deploy multiple times per day with lead times under one hour. Low performers deploy once a month or less, with lead times measured in weeks.
Platform engineering moves teams along this spectrum by removing the friction that kills deployment frequency: manual steps, inconsistent environments, fear of the pipeline. When deploying is boring and repeatable, teams do it more often. Smaller, more frequent deployments also tend to have lower failure rates because the blast radius of any single change is smaller.
A useful benchmark: teams that adopt standardised pipelines and IaC typically see deployment frequency increase three to five times within six months. Lead time drops because there are no more "fix the pipeline" cycles blocking releases.
Golden-Path Templates and Self-Service Infrastructure
A golden path is the opinionated, supported way to do something on your platform. It is not the only way, but it is the way that comes with documentation, tested defaults, and platform team support.
Here is what a golden-path pipeline template looks like in practice. Imagine a GitHub Actions reusable workflow that any team can reference:
# .github/workflows/service-pipeline.yml
jobs:
build-and-deploy:
uses: your-org/platform-workflows/.github/workflows/service-golden-path.yml@v2
with:
service_name: ${{ vars.SERVICE_NAME }}
environment: production
deploy_region: eu-west-2
secrets: inherit
The team calling this workflow does not need to know how container signing works, how the SBOM is generated, or how credentials are rotated. The platform team has encoded those decisions once, in a tested, audited template. The application team focuses on their code.
Self-service infrastructure follows the same pattern. A developer portal, built on something like Backstage or a lightweight custom catalogue, lets a team request a new PostgreSQL instance, a message queue, or a Kubernetes namespace by filling in a form. The request triggers a pull request against an IaC repository, which is reviewed and applied automatically once approved. No ticket to the DBA team. No waiting.
Observability as a Platform Capability
One of the clearest signs of a maturing platform is when observability stops being an afterthought. In a scripted pipeline world, logging and tracing are bolted on per-service, inconsistently, by whoever had time. In a platform engineering model, they are built into the golden path.
Every service deployed through the platform gets structured logging to a central store, distributed tracing via OpenTelemetry, and a base set of dashboards and alerts. Teams can extend these defaults, but they cannot accidentally ship without them.
This matters for DORA's time-to-restore metric. When an incident happens, the question is not "do we have any observability?" but "which dashboard do I open first?" A platform that answers that question before the incident saves hours during it.
SRE practices, particularly error budgets and service level objectives, fit naturally into a platform model. The platform team sets the SLO framework. Product teams define their own targets within it. Everyone is working from the same definitions and the same tooling.
Security and Credential Management in Modern Pipelines
The recent community interest in tools like Cordium, which sandboxes pipeline execution to eliminate raw credential injection, points to a genuine gap in most pipeline setups. Credentials injected as environment variables are a common attack vector. A compromised pipeline step can exfiltrate secrets that have access to production systems.
A platform engineering approach addresses this at the architecture level:
- Use short-lived credentials via OIDC federation between your CI system and cloud provider (no long-lived keys stored anywhere)
- Scope permissions to the minimum required for each pipeline stage
- Audit all credential usage centrally
- Treat pipeline configurations as code, with the same review requirements as application code
The Cilium project's published lessons on securing CI/CD for an open-source project make the same point: the attack surface of a modern pipeline is large, and the only scalable defence is a platform-level approach to secrets management, not per-team vigilance.
From Zero to Production in Weeks
The objection most engineering leaders raise is time. Building a platform sounds like a multi-year programme. It does not have to be.
The key is to start with the most painful problems and deliver value incrementally. A practical sequence looks like this:
- Week 1 to 2: Audit existing pipelines. Identify the two or three patterns that cover 80% of your services.
- Week 2 to 4: Build golden-path templates for those patterns. Include security defaults from the start.
- Week 4 to 6: Migrate two or three volunteer teams. Gather feedback. Fix what is broken.
- Week 6 to 8: Add self-service infrastructure for the most commonly requested resources.
- Week 8 onwards: Expand the catalogue, add observability defaults, and track DORA metrics to demonstrate value.
This is not a big-bang transformation. It is an iterative build, treated like a product. Teams get value early. The platform team gets feedback early. By week eight, you have something real that other teams want to use.
Conclusion
Platform engineering is not a trend to evaluate later. For any organisation shipping more than a handful of services, the cost of ad-hoc pipelines is already being paid in slow deployments, inconsistent security practices, and engineers spending their time fighting infrastructure instead of building product.
The investment in a genuine internal developer platform pays back quickly: higher deployment frequency, shorter lead times, better security posture, and engineers who are actually glad to deploy on a Friday.
How modernise.io Can Help
Modernise.io builds internal developer platforms as a core practice, from golden-path CI/CD templates and IaC module libraries through to developer portals and OpenTelemetry-based observability stacks. We bring the platform engineering model to organisations that need to move fast without accumulating technical debt, using the same DORA metrics framework described in this article to measure progress and demonstrate value to leadership. Our engagements are structured to deliver a working platform, not a slide deck: we work alongside your engineering teams, migrate real services, and leave you with the capability to run and extend the platform yourselves. If your organisation is spending more time maintaining pipelines than shipping product, we can help you build a platform that makes deployment the boring, reliable part of your week.
Get in touch →