The way these three get discussed implies a ladder. DevOps was the 2010s, DevSecOps bolted security onto it, and platform engineering is what comes next. Vendors reinforce this, because a ladder means everyone is behind and needs to buy something.
It is a bad model. Each of the three exists because a specific thing was broken, and if that thing is not broken for you, adopting the discipline buys you overhead and nothing else.
Here is the honest version of what each one is for.
DevOps answers "how do we ship faster without breaking things" — by removing the handoff between the people who write code and the people who run it. DevSecOps answers "is what we are shipping actually safe" — by moving security checks into the pipeline rather than into a gate at the end. Platform engineering answers "why does every team solve the same infrastructure problem from scratch" — by building paved paths that most teams use by default.
DevOps: The Handoff Problem
DevOps emerged because of a specific organisational failure. Developers wrote code and handed it to an operations team, who ran it. Developers were measured on features shipped; operations on stability. Those incentives point in opposite directions, and the result was a queue, a change advisory board, and a release every six weeks that everyone dreaded.
The fix was not a tool. It was giving one team responsibility for both writing and running a service, then automating the path between the two so that responsibility was bearable.
You still have a DevOps problem if: releases need a meeting, deploys happen outside business hours because they are risky, your developers cannot see production logs, or "it works on my machine" is still a sentence anyone says seriously.
DevOps is not "we have Jenkins" or "we hired a DevOps engineer". Hiring a person called a DevOps engineer to sit between dev and ops recreates exactly the handoff the practice was invented to remove — it just gives the wall a nicer name. The measurable outcomes are the DORA four: deployment frequency, lead time for change, change failure rate, and time to restore. If those have not moved, the title change did not help.
DevSecOps: The Timing Problem
Once DevOps worked, teams were deploying far more often. Security review, still a manual gate at the end, became the new bottleneck — or worse, was skipped, because the deploy cadence had outrun the review capacity.
DevSecOps moves the checks into the pipeline. SAST on commit, dependency scanning on build, container scanning before push, policy checks before apply. The economics are the argument:
That third number is the one worth sitting with. Most teams have the scanners. Most teams set an SLA of a week or less. And most teams miss it — which means the tooling is producing findings faster than anyone can act on them.
Adding scanners to a pipeline is a one-week project. Building the capacity to action what they find is the hard part, and it is where most DevSecOps programmes quietly fail. A Gartner survey of large enterprises found an average of 45 security tools per organisation. More scanners do not produce more security; they produce more findings, and findings nobody closes are indistinguishable from findings nobody generated.
There is a newer wrinkle. AI-generated code has been measured at roughly 2.74 times the vulnerability density of comparable human-written code, and around 80% of developers report trusting AI tool output without systematic security review. If your team adopted coding agents this year and your scanning did not change, your exposure did.
Platform Engineering: The Repetition Problem
DevOps gave each team ownership of its own deployment. That works beautifully at five teams and becomes a problem at forty, because now you have forty slightly different CI pipelines, forty opinions about secrets management, and a new service taking three weeks to reach production because its team is rediscovering everything from first principles.
Platform engineering is the correction. A small central team builds paved paths — a templated service, a standard pipeline, self-service environments — that most teams adopt because using them is genuinely easier than not.
- · Ticket-based: teams request, platform provisions
- · Standards enforced by policy and review
- · Measured on tickets closed
- · Teams route around it when they can
- · The platform team is a dependency
- · "Platform" is the new name for the gatekeeper
- · Self-service: teams provision themselves
- · Standards adopted because the path is easier
- · Measured on adoption and time to first deploy
- · Teams use it because it is the fastest route
- · The platform team is a force multiplier
- · Opting out is allowed, and rare
Can a developer deploy a new service to production without talking to anyone on the platform team? If yes, it is a platform. If the answer involves a ticket, a Slack message or an approval, it is an operations team with a modern name — which may be fine, but it will not deliver the outcomes platform engineering is supposed to deliver, and you should stop expecting them.
Side by Side
| DevOps | DevSecOps | Platform Engineering | |
|---|---|---|---|
| Problem it solves | Handoff between dev and ops | Security as an end-stage gate | Every team rebuilding the same thing |
| Shape | A practice teams adopt | A practice plus pipeline controls | A product a central team builds |
| Who owns it | Every product team | Shared — security enables, teams act | A dedicated platform team |
| Measured by | DORA four: frequency, lead time, failure rate, restore time | Time to remediate, vulnerabilities reaching production, SLA adherence | Adoption rate, time to first deploy, developer satisfaction |
| Fails when | It becomes a job title instead of a practice | Scanners outpace triage capacity | It becomes a gatekeeper with a new name |
| Worth it at | Any size | Any size handling user data | Roughly 5+ teams, or 30+ services |
Note the last row. DevOps and DevSecOps are worth doing at any scale. Platform engineering has a threshold — below it, the central team costs more than the duplication it removes, and you have taken two or three of your best engineers out of product work to serve four teams who were managing fine.
Which One Is Your Problem?
Where SRE Fits
SRE gets left out of this comparison and belongs in it. It is not a fourth competing discipline — it is a specific, opinionated implementation with a different emphasis.
Where DevOps says "share ownership of delivery", SRE says "define reliability numerically and spend the difference". You set an SLO, you derive an error budget from it, and when the budget is healthy you ship faster; when it is exhausted you stop feature work and fix reliability. It converts an argument between product and engineering into arithmetic.
Most organisations do not need the full Google model. Almost all of them would benefit from the one idea at its centre: decide what "reliable enough" means in a number, before the next incident, not during it.
A Sequence That Works
Measure the DORA four before changing anything
Deployment frequency, lead time for change, change failure rate, time to restore. These take an afternoon to pull from your CI and incident history, and they tell you whether you have a DevOps problem at all. Without them, every subsequent change is unmeasurable.
Week 1Fix delivery before adding security gates
Bolting scanners onto a pipeline that already takes two hours and fails intermittently produces a pipeline nobody trusts and everybody skips. Automated tests, reliable builds and one-click rollback come first — they are also what makes a security fix deployable within the SLA.
Month 1–2Add security scanning with triage capacity, not without
Start with dependency and secret scanning — highest signal, lowest noise. Before turning on SAST, decide who reviews findings and what the SLA is. A scanner with no owner is a dashboard, and 52% of teams are already missing the deadlines they set themselves.
Month 2–4Count your duplication honestly
How many distinct CI pipelines, Terraform patterns and deployment approaches exist? How long does a new service take to reach production? If the answers are small and short, you do not have a platform problem yet, and building one now would be expensive.
Month 4If you do build a platform, start with one golden path
One service template, one pipeline, one way to get a database — for the most common type of service you build. Not a platform covering every case. The test is whether a team adopts it voluntarily because it is faster, and you will know within a month.
Month 5+Measure platform adoption, not platform output
Percentage of services on the golden path, time from repository creation to first production deploy, and whether teams route around it. A platform nobody uses is not an unfinished platform — it is a product that failed to find users, and the fix is usually to ask them why.
OngoingIf You Are Under Forty Engineers
Most writing on this subject is aimed at organisations with hundreds of engineers, where platform teams are obviously warranted. For a smaller team the honest advice is different and rarely stated:
- Do DevOps properly. Automated pipeline, one-click deploy, one-click rollback, developers on call for their own services. This is most of the value available to you.
- Do the cheap half of DevSecOps. Dependency scanning, secret scanning, and a named person who triages. High signal, low noise, small overhead.
- Write down your conventions instead of building a platform. A well-maintained service template repository and a short document does 70% of what an internal developer platform does, at perhaps 5% of the cost.
- Steal the SRE idea without the SRE team. Define an SLO for your two most important services. That one habit prevents more incidents than most tooling.
Building an internal developer platform for eight engineers is the infrastructure equivalent of running Kubernetes for three containers. It will work. It is not free.
Frequently Asked Questions
Not Sure Which Problem You Have?
We do AWS architecture, DevOps, pipeline security and DR/BCP for production systems. Book a free 30-minute call — we'll look at your delivery metrics and tell you honestly whether you need a platform team or just a better pipeline.