r/platformengineering

I have noticed that most DevOps or Platform Engineering jobs require Prometheus, Grafana and sometimes Nagios. Which are the best platforms to get knowledge that can quickly be put into practice for these?

Question for all the platform or devops engineers out there.

I got laid off earlier this year have have been job hunting for almost 5 months now. My last title was platforms admin and where I owned a SaaD data platform on Azure. The scope of my job didn't have Terraform, Ansible k8s, or modern observability tools like Dynatrace. I have experience deploying docker containers using docker swarm.

I am not sure how to stand out. I don't see any new job postings or recruiters reaching out to me anymore. I have interviewed at half a dozen companies, reaching final rounds but no offers

Can someone help me make sense of this. I was a productive and competitive employee up until now. But not sure what's cracking up now?

Should i shift gears and try a different role? If yes, what would be more in demand Data engineer or Ai engineer.

What is the best way to learn and be interview ready?

After auditing dozens of Terraform environments across enterprise teams, I keep seeing the same drift patterns causing the same incidents. Here's the straightforward approach that actually works.

Detection starts with terraform plan -refresh-only. Run it daily at minimum. In CI/CD, add a drift check that alerts on any differences. For larger environments, continuous scanning is worth the effort – catching drift within minutes beats discovering it during an outage.

Fixing depends on what you find. Manual console changes get adopted via terraform import. Deleted resources get removed from state with terraform state rm. Configuration mismatches need either code updates or a terraform apply -refresh-only to force the cloud back to spec – but that last one requires understanding what you're overriding.

Prevention is where mature teams focus. IAM policies that block manual changes to tagged resources. Lifecycle rules like prevent_destroy on critical assets. Clear tagging conventions so everyone knows what's managed. And most importantly, an audit trail that tells you who changed what and why.

The teams that handle drift well don't just react to it. They build detection into their workflows, establish clear remediation playbooks, and continuously tighten guardrails based on what they learn from past incidents. What patterns have you seen across your teams?

Why Meta, Amazon, and Microsoft killed their token use leaderboards.

Hey everyone,

I'm a [B.Tech](http://B.Tech) Third Year CS student currently preparing for internships and freelance work. I have mostly built full-stack SaaS projects so far.

My current projects include:

* FinSight AI — finance management platform with analytics + AI features * BrainLoop — AI-based personalized learning assistant * DayFrame — productivity/journaling SaaS

My stack is mainly Next.js, React, TypeScript, Node.js, Express, PostgreSQL, MongoDB, Prisma, etc.

I feel like my projects show frontend/full-stack skills, but most of them are still around dashboards, CRUD, and API integrations. For my next major project, I want to build something that shows stronger backend/system design skills instead of another AI app.

I'm thinking about building a lightweight observability platform (inspired by Sentry/Datadog).

The idea is:

* developers integrate a small SDK into their app * the SDK captures errors, API performance, and events * backend processes this data * dashboard shows errors, latency, logs, and application health

Not trying to recreate Datadog, but more like a smaller developer tool to learn things like SDK design, event processing, queues, real-time updates, and backend architecture.

Do you think this is a good direction for a portfolio project, or am I overengineering? Would recruiters/internship reviewers value this type of project, or would a more traditional full-stack app be better?

Would love opinions from people who have built/hired for backend-heavy roles.

For those working in Cloud, SRE or Platform Engineering, what does a normal day look like for you?
What skills do you wish you had focused on before getting into the role, beyond the usual soft skills, networking and Linux? I’ve built projects around microservices, multi tenant , DevOps workflows, IaC with good security pratices, but I don’t have direct job experience yet. Am I on the right track if I keep building and improving, or is there something important I’m missing?

I've been in enough job specs, conference talks, and internal debates over the last year to notice a pattern: half the "Platform Engineer" postings I read are describing exactly what a senior DevOps Engineer already did five years ago. The other half are describing something genuinely different: a dedicated internal product team building paved roads and self-service tooling for other engineers, with its own roadmap and its own users (the org's own devs).

I don't think this is just semantics, but I also don't think the distinction is as clean as the conference talks make it sound. Genuine question for people who've actually sat in both seats, not just read the thinkpieces:

Where do you draw the line? A few candidate answers I keep going back and forth on:

●      DevOps is a set of practices/culture (CI/CD, IaC, shared ownership of ops); platform engineering is a specific team/role that productizes those practices for internal consumers. Under this framing, "platform engineer" isn't a rebrand. It's what you call the person once the team gets big enough to need a dedicated builder instead of everyone doing their own DevOps.

●      Platform engineering is what happens when "you build it, you run it" quietly failed at scale, and someone had to become the paved-road team so product engineers could stop reinventing Terraform modules badly.

●      It's mostly branding, and a lot of "Platform Engineer" postings are just "Senior DevOps Engineer, but the title tests better in this hiring market."

What's made me second-guess my own take: at companies under maybe 40-50 engineers, I've basically never seen a real separation. It's the same 2-3 people doing both, and "platform engineering" there is just a slide in a deck, not an org reality. It seems to only become a real, distinct discipline somewhere past that scale, and I'm not sure where.

Curious where people who've actually lived through the transition, either building a platform team from scratch or watching DevOps quietly get relabeled, land on this. Real difference, or mostly vibes and a better-selling job title?

Hi folks, security professional here looking for some insight from platform engineers who have had success implementing Account vending in AWS, GCP or Azure.

If my objective so to achieve self-service account vending (via GitOps) what would you recommend? What were some landmines you hit in your deployment?

I'm trying to reduce the amount of click-ops and this seems like a low-risk, high value start to pushing us more towards platform engineering.

Any advice is welcome

Hi Guys, Is this JD for Platform Engineer or DevOps Engineer?

Key Responsibilities

Design, build, and manage highly available Kubernetes clusters across hybrid environments (on-premises and cloud platforms such as AWS EKS, Azure AKS).

Deploy and manage applications manually using tools such as kubectl and Helm, with growing integration of GitOps practices (e.g., ArgoCD).

Implement and manage observability stacks using Prometheus, Grafana, Loki, and Mimir to monitor infrastructure, applications, and system performance.

Define, monitor, and improve SLA/SLO/SLI metrics and alerting systems to ensure platform reliability.

Automate provisioning and configuration of infrastructure using Terraform, Helm, and scripting languages (e.g., Bash, Python).

Plan, implement, and test backup and disaster recovery (DR) strategies using tools like Velero, Commvault, etc.

Manage Kubernetes-native networking, storage, and security configurations (Ceph, NFS, Ingress, PodSecurityPolicies, etc.).

Configure and enforce Kubernetes security best practices using RBAC, OPA/Gatekeeper, NetworkPolicies, and secrets management tools.

Integrate and operate Kubernetes ecosystem tools such as Karpenter, MicroK8s, Service Meshes, and kubectl plugins.

Conduct root cause analysis (RCA) and lead resolution efforts for incidents.

Participate in the on-call rotation for platform availability and incident management.

Maintain up-to-date documentation, architecture diagrams, runbooks, and SOPs.

Mentor engineers and advocate for Kubernetes, security, observability, and deployment best practices across teams.

Continuously stay informed of industry trends in container orchestration, GitOps, security, and cloud-native tooling.

Required Qualifications

5+ years of IT/Infrastructure/DevOps experience, with 2+ years in Kubernetes operations in production environments.

Strong hands-on experience in Kubernetes architecture, cluster operations, and manual application deployment practices.

Intermediate-level experience in Kubernetes Security, including:

Cluster hardening, secrets management

Pod Security Standards (PSS), OPA/Gatekeeper

Network policies, image scanning, and runtime protections

Intermediate experience with ArgoCD for GitOps-style Kubernetes deployments.

Solid proficiency in Linux system administration (Ubuntu, CentOS, RHEL) and troubleshooting.

Hands-on experience with Kubernetes-native storage (e.g., Ceph, NFS) and persistent volume provisioning.

Strong familiarity with observability tools: Grafana, Prometheus, Loki, Mimir, etc.

Proficiency in Infrastructure as Code using Terraform, Helm, and scripting.

Experience with Velero, Commvault, or similar for backup and DR.

Experience operating and optimizing cloud-native Kubernetes platforms like EKS, AKS.

Exposure to tools like Karpenter, MicroK8s, Service Mesh, and Ingress Controllers.

Familiarity with AI/ML workloads running on Kubernetes is a plus.

Excellent collaboration, communication, documentation, and incident resolution skills.

Preferred Qualifications

Kubernetes certifications: CKA, CKAD, or CKS.

Strong understanding of container security, networking, and distributed system architecture.

Experience using Portainer for container and Kubernetes management.

Advanced knowledge of Grafana and other enterprise-grade observability tools.

Experience managing large-scale Kubernetes clusters (200+ nodes) is highly preferred.

Prior experience supporting production-grade, high-availability platforms and environments.

I’m developing HybridOps Core, an MIT-0 open-source research implementation for governed infrastructure operations, and I’m looking for practitioners willing to give a short, candid technical assessment of specific parts of the work.

The work examines whether infrastructure intent, environment policy, dependency ordering, preflight, execution, verification and run records can be expressed through a stable runtime contract across heterogeneous environments.

I’ve published several technical papers alongside the implementation and opened focused GitHub review threads for independent critique. The aim is not a code audit or unpaid QA. Reviewers are being asked to assess the architecture, operating assumptions, failure boundaries and practical relevance of the work.

Current review areas include contract-driven runtime design, image lifecycle and verification, reproducible network environments, infrastructure authority and source-of-truth boundaries, and recovery operations.

If one of those areas overlaps with your experience, comment with the area and I’ll send the relevant paper and review thread. Critical findings and counterexamples are welcome.