From DevOps to Platform Thinking: What Changed for Me

Editor’s Note: This blog is adapted from a talk by Turja Narayan Chaudhuri, global platform engineering lead and DevOps Institute ambassador. In this session, he offers a personal reflection on how DevOps evolved—and why internal platforms are becoming essential for modern engineering teams. Drawing from over a decade in infrastructure and community leadership, Turja breaks down the growing complexity developers face today and explains why platform engineering is not a buzzword but a maturity model for sustainable software delivery.

Hi, I am Turja Narayan Chaudhuri. I have spent the last fourteen years working across the layers of technology infrastructure, and today I lead a global platform engineering team spread across six countries. I also happen to be a DevOps Institute ambassador, a Platform Engineering ambassador, and an active member of the CNCF Platforms Working Group. I have been running the HashiCorp and Docker user groups in Kolkata for some time now. But today, I want to step back and talk about something that has been evolving under the radar: the shift from DevOps to Platform Engineering.

I am speaking here as myself, not as a representative of any company. This is a personal reflection on how I have watched this evolution unfold—and what I believe it means for anyone building technology today.

When the term DevOps first entered our vocabulary, it was never about tools. It began as a cultural shift, an effort to bring developers and operations teams closer together. The idea was simple: if you build it, you run it. I remember watching the original Velocity Conference where this concept was first coined. That moment stuck with me. The vision was clear—blur the boundaries between development and operations to speed up delivery and improve reliability.

Over time, though, something changed. DevOps became synonymous with CI/CD pipelines, GitHub repos, Docker containers, and monitoring dashboards. Tools overtook the culture. And somewhere along the way, the philosophy that once drove this movement got diluted. That does not mean DevOps failed—it simply means we needed to rethink how to get the best out of it.

I have seen the blog posts. "DevOps is dead." But the numbers tell a different story. The DevOps industry is valued at over twenty billion dollars. Enterprises across sectors continue to invest in DevOps tooling and practices. DevOps is not going anywhere. But not all DevOps implementations are equal.

That is where the DORA metrics come in—lead time, deployment frequency, mean time to recovery, and change failure rate. These metrics expose a simple truth: although everyone claims to be doing DevOps, only a few are doing it well. Some teams deploy in minutes. Others take weeks. Some recover from failure in an hour. Others need days. Some know their metrics. Others do not even track them.

This gap between top performers and the rest is not just about tools. It is about how you build your systems. And that is where Platform Engineering enters the picture.

I want to share something that changed the way I think about DevOps: the rise of internal developer platforms. These are reusable sets of tooling, services, and infrastructure built not for the end customer, but for developers inside the company. In other words, your customer becomes the engineer who is building business-facing applications.

Let me give you an example. Suppose you need logging and observability for your new application. One way is to build it yourself using open-source tools. That works, but what if ten other teams in your company are doing the same thing? That is duplication of effort, wasted time, and increased inconsistency.

Now, imagine there is a platform team that has already built a certified, secure observability package. All you need to do is call an API or drop in a module. You save time. You avoid mistakes. You focus on what really matters: building features.

This is what a platform does. It abstracts away the undifferentiated heavy lifting and gives developers a self-service experience. Compute, storage, authentication, monitoring—all available as secure, reusable building blocks.

At this point, someone usually asks—so is not this just AWS or Azure? The answer is no. Cloud providers give you raw infrastructure. Platform teams build on top of that, adding organisational standards, enterprise security, and domain-specific integrations. Your internal platform might use Azure under the hood, but the value lies in the abstraction, the consistency, and the developer experience.

These platforms are not theoretical. They exist in the real world. In my own company, we started our platform journey in 2018. We now have teams across geographies building tools that other developers rely on. Observability, data ingestion, secure transfers—these are now plug-and-play within our ecosystem.

When I began my career, I wrote Java code, pushed it to version control, and called it a day. I did not worry about Terraform, Prometheus, or GitHub Actions. That was someone else's concern.

Today, developers are expected to know everything. Infrastructure as code, security policies, container orchestration, tracing identifiers across microservices—the cognitive load is immense. And that is where platform engineering becomes more than a technical choice. It becomes a way to protect the developer's focus.

By offering composable, well-documented internal tools, a platform team reduces this burden. Developers no longer need to become experts in ten different systems just to get their feature out the door. They just need to plug into the platform.

Let me be clear: platform engineering is not a replacement for DevOps. It is a progression. DevOps engineers build and ship applications. Platform engineers build the reusable infrastructure that makes that possible.

Think of platform engineers as internal product teams. Their users are developers. Their product is the platform. And yes, the compensation often reflects the specialisation—platform roles tend to be paid significantly higher, reflecting the impact and complexity involved.

In many organisations, including mine, these are distinct tracks. You do not become a platform engineer by slapping a new label on a DevOps title. You become one by thinking like a product builder inside an engineering team.

Platform engineering is not something you install overnight. It takes time. Most companies are still in early stages—building out automation, documenting interfaces, and standardising practices. Maturity is gradual. You begin with provisioning by request. You evolve into managed self-service.

And like any journey, the sooner you start, the better you position yourself for the future.

Gartner has already listed platform engineering among the top four strategic technology trends. CNCF has formed a working group to shape its standards. Surveys show that ninety-two percent of companies are either adopting or expanding platform engineering practices. The shift is happening.

So if you are a DevOps engineer with a few years of experience, now is the time to explore this path. Learn how internal platforms are built. Think about developer experience as a product. Your next role might not be in application delivery, but in building the systems that make application delivery faster, safer, and more scalable.

DevOps is alive and well. But if you want to move faster, break fewer things, and scale more sustainably, you need a platform mindset. That is what top-performing teams are already doing. That is what the future looks like.