Initially, I thought platform engineering was just a rebranding of DevOps. Spending more time on the topic, I now think of it differently. I see DevOps as a prerequisite for platform engineering. While there is a large overlap in the problems DevOps and platform engineering seek to solve, hardly any organisation starts with platform engineering from the get-go. Most build their platform engineering initiatives on top of tooling and capabilities they have built during their DevOps days.
What is DevOps? What is Platform Engineering?
DevOps
Very simply put, DevOps is about the very fundamental automation that is needed in software development. It’s about automating build, testing and deployment. When that all works, observability and monitoring are a nice-to-have on top.
DevOps arose because there was a lot of pain in running applications built by developers who didn’t know the first thing about running applications. DevOps sought to bring operations and development closer together. “Throwing things over the fence” was replaced by “you build it, you run it”. This brought software engineer’s mindset to operations as well: Instead of focusing on how to best ensure stability of an application, the focus shifted to automation. DevOps teams sought to reduce manual effort as much as possible.
Platform Engineering
Platform engineering starts when this core automation is in place already. It’s about increasing transparency of the automation that is in place, and about enabling self-service. Platform engineering teams build developer platforms, which allow software developers to discover what infrastructure, applications and deployments already exist and how to use them, and allows them to deploy things in self-service.
In DevOps days, the ideal would be a software engineer pushing their code changes to a repository and not having to worry at all about what happens next. They would get a build report or something, possibly via email, possibly not at all, or maybe just an error notification through some channel if their build failed. That’s it. The idea was to automate everything that comes after the push to the repository.
Platform Engineering is now about empowering software engineers to actually see what happens after their push, get more detailed visibility and feedback, and also to decide what they need. In addition, it’s also about taking the automation that is already in place for the CI/CD pipeline and using it for other, related use cases that need a lot of the same capabilities.
For example, developers may be able to deploy development environments for themselves using the developer platform. The deployment of the development environment takes many of the automation pieces of the CI/CD pipeline, but decouples it from a push and allows the developer to create it in self-service.
So in platform engineering days, a software engineer starts their day by provisioning a development environment via the developer platform. There, they make their code changes. After a push, they can see the results of the tests and the status on the CI/CD pipeline in the developer platform. When the build fails, or tests fail, they should be able to get detailed information on that in self-service. For example, they could log into the test environment, or ssh into the test server, and take a look at additional logs.
They could then provision a feature-branch system, with custom configuration they choose, to deploy the failing environment to, and continue to work on it there. They should be able to do all of that in self-service, without bothering a DevOps or platform engineer at all.
The Reality
Of course the reality is always somewhere in between the two. Many CI/CD tools already allow for a lot of transparency. Many DevOps teams may already have provided some self-service tools to software engineers, thereby doing platform engineering without even realising it.
When a company that has 0 automation in place starts to do platform engineering, they will still have to do all the DevOps things. They will still have to build a CI/CD pipeline. They will still have to build all the automation that goes into that. Only when something is automated can it be offered to software engineers in self-service.
The Rebellion
Besides the focus on self-service, platform engineering has also arisen as a counter-movement or a bit of a rebellion against DevOps. DevOps was understood by many as making the lives of software engineers harder. “You build it, you run it” meant that DevOps engineers were expected to have the skills of both a developer and an operations expert.
Platform engineering, on the other hand, is about simplifying things again for software developers. It’s about reducing the complexity developers are exposed to by moving specialised deployment and infrastructure knowledge into a dedicated team, which provides those things as services to software engineers.
Golden Paths
One of the hardest things in platform engineering is figuring out the right amount of abstraction. How much detail do developers need in order to do their job well? This is why platform engineering is centered around the idea of “golden paths”: templates or documented and supported ways of doing something, that still allow developers to do things differently, e.g. “leave the golden path” and customise an environment, if they need to.
Summary
The below table gives a structured overview of the differences between DevOps and platform engineering.
| DevOps | Platform Engineering | |
| Focus | Culture, collaboration, CI/CD, automation | Building internal developer platforms (IDP) for self-service |
| Goal | Enable faster, reliable software delivery | Abstract infrastructure complexity for developers |
| Approach | Automate pipelines, IaC, monitoring | Provide reusable tools, templates, and APIs |
| Scope | End-to-end software delivery lifecycle | Developer experience & infrastructure abstraction |
| Key Users | Developers, Ops, Security | Developers consuming the platform |
| Challenges | Requires deep expertise, often ad-hoc tooling | Needs maintenance, requires platform team |
In short:
- DevOps is a cultural and technical approach to improving collaboration between development and operations.
- Platform Engineering operationalizes DevOps at scale by providing a structured, self-service platform for developers.
Are you ready for Platform Engineering and building an IDP? Check out how Cloudomation can support you as a backend IDP tool.
