DEV Community: Gaurav singh

DevOps Is About Shipping Software. Platform Engineering Is About Scaling the Way Teams Ship.

Gaurav singh — Sun, 19 Jul 2026 19:58:39 +0000

Infrastructure teams are changing roles as organizations adopt cloud native technologies. DevOps is all about improving collaboration, automation and delivery, and Platform Engineering takes this a step further by building internal platforms that allow developers to move faster with fewer operational hurdles.

Good platforms abstract away the repetitive infrastructure tasks without sacrificing flexibility. Platform Engineering provides reusable building blocks so that developers are able to focus on writing business logic, instead of each team having to re-invent deployment pipelines, Kubernetes configs, or monitoring stacks.

The key principles of a successful platform are:

Deployments of self-service infrastructure
CI/CD pipelines standardized
Infrastructure as Code
Security and compliance built in
Centralized monitoring and observability
Good documentation & developer experience

The point is not to hide complexity, it’s to manage complexity. This enables developers to provision environments, deploy applications and troubleshoot issues without waiting on platform teams. This allows organizations to deliver software faster while maintaining consistency and reliability.

This is what Platform Engineering means to me and what makes it exciting. It’s not just about managing Kubernetes clusters or cloud infrastructure, it’s about building systems that enable other engineers to do their best work.

What are you working on in platform engineering at the moment?

Structuring Terraform Projects for Multiple Environments Without Copy-Paste Drift

Gaurav singh — Sun, 19 Jul 2026 11:53:23 +0000

The first time I had to manage infrastructure across multiple environments, the temptation was to make the setup as simple as possible. One folder for dev, one for staging, one for prod, and the same Terraform files copied into each one.

That feels practical at first. Then the environments start changing in slightly different ways, and the copy-paste approach becomes its own problem. One environment gets a fix and the others do not. One variable gets updated in staging and never makes it to prod. A small tweak that should have been straightforward turns into a comparison exercise because nobody is quite sure which folder is authoritative anymore.

I have seen enough of that kind of drift to stop trusting the copy-paste model.

What works better is separating reusable infrastructure from environment-specific values. In practice, that means modules for the building blocks and separate environment folders for dev, staging, and prod. The module defines what the infrastructure does. The environment folder decides how it should look in that context.

That distinction matters a lot once the systems are real. I have worked in environments where infrastructure was being moved, deployed, or recovered across AWS and Azure, and the biggest source of confusion was often not the cloud provider. It was the lack of a clean boundary between shared logic and environment-specific settings. Once that boundary is clear, reviews become much easier and accidental drift becomes much less likely.

I also stopped liking Terraform workspaces for most real use cases. They look convenient until the environments become meaningfully different. If dev needs a smaller instance type, prod needs a different network range, and staging needs to stay close to production but not identical, workspaces start pushing you toward conditionals that make the code harder to reason about. That ends up feeling worse than just structuring things properly from the beginning.

The module-plus-environment approach is boring in the best way. A VPC module stays generic. An ECS service module stays generic. An RDS module stays generic. The environment folder passes in the values. That keeps the code easy to scan and reduces the chance that a prod-only change leaks into dev by accident.

State separation is non-negotiable too. If dev and prod point at the same backend key, you are asking for trouble. Keeping each environment’s state isolated is one of those unglamorous decisions that prevents very glamorous incidents later. I have learned that infrastructure mistakes are almost always easier to prevent than to clean up.

I also strongly prefer using CI for plan and apply instead of applying from laptops. Infrastructure becomes much easier to trust when it is reviewed the same way application code is reviewed. That gives you a clear history, a predictable workflow, and fewer surprises when something changes.

A few other habits have saved me time: pin module versions, keep secrets out of committed tfvars files, and run periodic drift checks even when nobody is actively changing infrastructure. Manual console changes happen. Drift happens. The only question is whether you notice before it starts causing confusion.

The first time you set this kind of structure up, it feels like extra work. After you have lived through enough environment drift, it starts feeling like the only sane way to do it.

You Probably Do Not Need Kubernetes Yet

Gaurav singh — Sun, 19 Jul 2026 11:46:20 +0000

I’ve seen enough docker setups to know that a lot of people reach for Kubernetes before they’re ready for it.

It doesn’t mean Kubernetes is bad. It's a solid platform and makes a lot of sense in the right environment. But for many teams, particularly smaller teams, the real question is not if Kubernetes is powerful. It’s a question of whether the team has the bandwidth to run this thing without slowing down everything else.

I have seen this in practice, not in theory. When I was dealing with containerized deployments, Azure VM setups, Keycloak in Docker, and even NLP pipeline packaging, the toughest problems were never about orchestration as a concept. The challenges were about basic operational friction: container permissions, image size, missing model files, HTTPS requirements, disk space and deployment behavior that needed careful debugging. Kubernetes would not have made those problems go away. In some cases it would have put another layer over them.

That’s the part people don’t get. The use of machines is not expensive (Kubernetes). It is expensive because someone has to understand the cluster, the networking, the access model, the upgrade path, the deployment workflow and the failure modes. That's a lot to ask from a small team still trying to get a product out.

The “we need Kubernetes for scale” argument is also played up a lot. Most early-stage systems aren't managing multiple teams with dozens of services. They are running one API, one worker, maybe a DB, and a few background jobs. “That’s a deployment problem, that’s not a platform-complexity problem.

In that setup I tend to think simple is better. A well-managed Docker Compose deployment, PaaS, ECS Fargate or Cloud Run can handle surprising amounts of real traffic without requiring the team to maintain a whole orchestration layer. That trade off often makes more sense than adding Kubernetes just for the sake of being more “serious”.

So when does Kubernetes start to make sense? When the organization actually grows into it: multiple teams deploying independently, real scheduling complexity, platform level networking needs, portability concerns, or workloads that actually benefit from orchestration at scale. At that point the operational overhead is easier to justify because the team is big enough to carry it.

I think the simplest question still is the cleanest: does the pain of not running Kubernetes outweigh the pain of running it, with the team you actually have right now?

If the honest answer is “not really, but we think we should,” that’s usually not a technical reason. It’s pressure, it’s habit, it’s comparing to the bigger company’s stack. And that’s a very expensive reason to adopt infrastructure.”

Cloud Cost Optimization Is a Culture Problem, Not a Tooling Problem

Gaurav singh — Sun, 19 Jul 2026 11:36:44 +0000

I paid my first real attention to cloud cost not in a strategy meeting or on a FinOps dashboard. It was that something that should have been simple had become expensive, and nobody saw it.

That’s how these things normally go. You don’t just wake up to a huge bill out of the blue. It grows out of a long series of reasonable decisions: keep the environment running a little longer, size the VM a little bigger just in case, leave staging up because someone may need it later, do not touch the database because the safer option is to leave it alone.

I have seen this pattern from both sides of the infrastructure work. The platform itself was rarely the expensive part on AWS, on Azure, during migrations, or keeping services alive for real usage. It was the routines around the platform. When we moved workloads from EC2 to Azure VM setups, the cost difference often wasn’t the cloud provider but how deliberately we managed the environment once it was up.

The tools are good, but they are not magic. Cost dashboards tell you what resources are oversized, idle, and wasting money in what environments. They can’t tell you why nobody took ownership of that resource in the first place. That’s the real problem.

Many teams treat cost optimization as a cleanup sprint. So, someone is charged with finding waste, they cut the obvious stuff, the bill comes down a bit and everyone moves on. That will work one time. Twice maybe. But if we keep making decisions about infrastructure the same way, we will get the same waste back.

The most important thing for me is that the cost has to show up early, not late. It should be in the conversation when something is being provisioned, not just when finance starts asking questions. Now is the time for a team creating a new environment, building a new service or choosing a larger instance size “just to be safe” to ask if the choice actually matches the workload.

I’ve also learned that ownership is more important than reporting. A cost report that doesn't go anywhere specific gets ignored. If each team is looking at their own spend, it’s much harder to ignore a simple weekly review, because now the number is owned by someone. The same applies to tagging. Tags will drift if they are only a reminder on a wiki page. They happen if Terraform or deployment code needs them.

That’s why cloud cost control is an engineering discipline more than a finance job. It’s not really about maximizing every dollar out of it. It’s about developing the habit of asking, before you deploy, whether this is the right shape of infrastructure for the problem you really have.

That’s the part most tools can’t do for you.