You Build It, You Run It!

When it comes to DevOps and Platform Engineering, people seem to swing between extremes. Some argue that developers should delegate everything to “DevOps teams”, while others believe developers should manage infrastructure entirely on their own.

That’s a big misunderstanding of both DevOps and PE (surprising?).

I recently came across an argument that developers should not need to know (or even care) about the runtime of their systems. The idea was that platform teams should abstract it away completely so developers do not have to think about it. This view misunderstands how developers and platform teams should work together.

Good platform engineering makes it easier for developers to deploy and operate their applications. It removes unnecessary complexity and provides the right tools for self-service. But this does not mean developers should be unaware of how their code runs. A complete lack of understanding leads to poor performance, unreliable systems, and difficult troubleshooting.

“You build it, you run it” is not just a phrase. It means developers take ownership of their applications beyond writing code. They need to understand how their systems behave in production, how they scale, and how they recover from failures. Without this awareness, platform teams end up firefighting issues that developers could have anticipated.

Performance, security, and cost are all tied to the runtime. Cold starts, memory limits, and CPU throttling affect how applications perform. Security depends on runtime isolation, access controls, and patching vulnerabilities. Cost efficiency is also a concern when using modern cloud platforms.

Platform engineering provides tools and automation to make this easier, but it does not remove the need for developers to understand what happens when their code runs.

Developers in product teams do not need to be infrastructure experts, but they cannot afford to be completely disconnected from the runtime. The goal of platform teams is not to hide everything. It is to give developers the best possible environment while keeping them informed. Owning code means owning how it runs.

Originally published on LinkedIn.