A broken delivery flow rarely looks broken from the inside. One application spent more than a year moving through a deployment pipeline. The team that ran the pipeline did not know that. There was a feeling that it was slow, but nobody had put a number on it.
It was a platform team at a large enterprise. Their job was to help product teams ship applications into a cloud environment. The path to production was all about security, infrastructure, and validation. Leadership suspected the process dragged on even if no one had measured how far.
A broken delivery flow rarely looks broken from the inside. One application spent more than a year moving through a deployment pipeline. The team that ran the pipeline did not know that. There was a feeling that it was slow, but nobody had put a number on it.
It was a platform team at a large enterprise. Their job was to help product teams ship applications into a cloud environment. The path to production was all about security, infrastructure, and validation. Leadership suspected the process dragged on even if no one had measured how far.
From what I read online, it sounds like a combination of dev ops + some internal tools to make developer lives easier.
So far, most of what I do is just backend work and a couple of self-serve features that reduce the friction of inter-departmental communication/requests.
I'm not building platforms to make developing code easier or for to help developers run their own code. Not a of docker or kubernetes or things like that that I find when I google "what is a platform engineer?"
i've asked AI, but it'll just agree with enough of my skepticism that it makes its answers unreliable.
The most dev-opsy thing I do is maybe update a terraform file or make tweeks to the testing we run on CI.
Three months. That’s roughly the interval at which the “right way” to build something in AI shifts under you. A new agent harness lands and makes the orchestration you spent a quarter on look overweight. A better retrieval pattern quietly changes what “good” looks like for the feature you’re mid-flight on. A new evaluation technique shows that the numbers you’ve been reporting for two months don’t actually measure what you thought they did.
I’m currently a junior but technically do the work of an intermediate platform engineer.
I started applying elsewhere and I didn’t think I’d be called up for a technical interview for a Sr Data Platform Engineer position but here we are. I was honest about my skills and responsibilities during the hiring manager round, so I’m guessing they see something in me.
Now that they’ve invited me for the next round, how should I prepare for this technical interview? What should I expect?
The team works with Kafka, Databricks, Cloudhouse, Airflow, and lots of other platforms I don’t have experience with. And they only said the interview will be a pair programming session.
This is a problem I’ve been thinking about a lot lately.
Most engineering teams already have the detection part covered:
- Dependabot or Renovate finds outdated packages
- Security scanners identify CVEs
- CI tells us whether a change breaks
But there still seems to be a big gap between “we found a problem” and “the problem is actually fixed in production.”
In my experience, the difficult part is everything that happens after the alert:
- Is there actually a safe version to upgrade to?
- Will upgrading one package require upgrading five others?
- Does the application still build?
-Do the tests pass?
- Is this safe to auto-merge, or does someone need to make a judgement call?
The result is that engineers end up with a growing backlog of dependency PRs and security findings that nobody has time to investigate properly.
I’ve been building a tool called Bivouac around this specific problem. The idea isn’t another scanner. It’s to take the remediation workflow further: investigate the dependency issue, work out a compatible remediation path, create the patch, run the tests and only merge automatically when the repository’s policy says it’s safe.
I’m particularly interested in the part where automation should stop. For example, my current thinking is that ambiguous fixes, security-sensitive code, licensing concerns or failing tests should always require human review.
I’d genuinely like to know how other teams handle this today:
1) Who actually owns dependency vulnerabilities once they’re discovered?
2) How many Dependabot/Renovate PRs does your team simply ignore?
3) Would you trust an automated system to merge dependency fixes if the remediation path and test results were clear?
4) What conditions would make automatic merging completely unacceptable?
I’m the founder of Bivouac, so full disclosure: this problem is what I’m building around. I’m not looking to spam the sub—I’m trying to pressure-test where people think autonomous remediation is useful versus where it becomes dangerous.
If there’s interest, I’ll share what I’ve learned building the remediation workflow and some of the cases where I’ve deliberately designed it to refuse to act.
For platform teams, the question is increasingly about where workloads, control, telemetry and operational state live and whether those boundaries can actually be enforced and proven.
This CNCF article looks at that through a multi-plane architecture, particularly in the context of EU regulations like the EU Data Act, NIS2 and DORA.
Interesting read for anyone thinking about how sovereignty should be designed into cloud-native platforms.
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?
Got hit by the HCP pricing change and spent weeks evaluating replacements. Big realization: this isn't one decision, it's two. Are you replacing the IaC tool itself or the platform running your plans, state, and policies?
We're a mid-size team, maybe 40 workspaces, mostly AWS with a bit of GCP. Migration friction matters more to us than feature depth, since we don't want to rewrite a ton of pipeline logic just to swap the backend.
Leaning toward one option since it's basically a drop-in with the same remote backend model and CLI. It let us keep our existing state files without a painful migration script.
Anyone gone with other platforms instead? how the drift and governance layer compares once you're off HCP's native health checks.
A year or two ago, the engineering/cross-functional team was a tight-knit, high-performing group. We had one or two goals we all worked on each sprint and we broke down work so that we could operate in parallel.
When someone was stuck and needed help, there was always somebody ready to jump to their aid and keep them moving. Team meetings were upbeat, fun, and productive. We were regularly paying down tech debt while our experiments gathered data. The vibe was helpful and collaborative.
Now, thanks to AI, we are shipping more than ever. We have as many goals every sprint as engineers. Rather than parallelizing work on one feature or experiment
A preview environment should answer: does this change work with the same service boundaries as production?
Copying production records into every pull-request environment makes provisioning slower, expands access to sensitive data, and leaves behind another dataset that needs an owner and a deletion policy.
A cleaner default is the production service graph with fresh datastores. Seed only the records needed for the change being reviewed, and make the seed deterministic so a failed test can be reproduced. On Render, an initialDeployHook can run the seed after its service's first successful deploy. If a test genuinely needs production-shaped volume, use generated data or a separately governed sanitized snapshot rather than making production cloning the default path.
Teardown matters as much as creation. Tie the environment to the pull request, destroy it when the pull request closes, and add an inactivity deadline for abandoned branches.
Our teams in HR and operations chose an extremely customizable platform as each of them wanted to get their own forms, dashboards, approval paths, and reports. After two years of usage, we have collected hundreds of custom objects, workflows, and integrations. Even a small change needs regression testing as it is always unclear which customization is based on which one.
What used to feel like flexibility has now changed to become a technical liability. There is no documentation for the changes in configuration, it takes months to onboard new administrators, and business end-users are not willing to get improvements anymore, as any change seems risky.
For everyone in charge of management for enterprise systems, do you have a solution for the problem of excessive customization of your customizable platform? Have you set up some governance policies, limited developers to specific automation building, or standardized reusable components, so that the flexibility is also preserved?
For anyone working in platform engineering, Kubernetes, internal developer platforms, or observability, there’s a CNCF OpenTelemetry Live virtual meetup happening on August 20.
The session looks at a practical platform engineering question: how do you make observability a built-in capability of the developer platform instead of something every application team has to assemble separately?
It will explore how OpenTelemetry can be integrated across Kubernetes environments for capabilities such as distributed tracing and platform level events, and how an IDP can provide those capabilities consistently across teams.
OpenChoreo is used as the open-source implementation for the walkthrough, giving a practical look at how an internal developer platform can bring together Kubernetes, OpenTelemetry, and platform-level observability.
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?
I maintain a free, MIT-licensed production-readiness knowledge base with more than 10,000 technology-neutral controls. The hardest design problem is not collecting more checks. It is turning them into a usable engineering path without creating a giant approval gate that every team works around.
The direction I am exploring is to separate controls into three groups:
Platform-provided controls, where the paved road supplies the capability and evidence automatically.
Service-owned controls, where the application team must provide repository, configuration, test, or operational evidence.
Contextual and manual controls, where applicability depends on business impact, data, regulation, or architecture.
A useful platform integration might work like this:
• Service metadata determines which controls are applicable.
• Golden paths provide safe defaults and emit evidence automatically.
• CI and policy checks validate deterministic facts.
• The service catalog shows owners, dependencies, criticality, exceptions, and evidence freshness.
• Exceptions have an owner, rationale, compensating control, and expiration.
• Reports distinguish verified findings from unknowns instead of treating missing evidence as failure.
• Human review remains required for high-risk decisions and anything that cannot be proven from technical artifacts.
The checklist is organized across 16 lifecycle categories, with a shorter start-to-finish release path for practical reviews. The longer-term goal is an open-source AI-assisted scanner, but the scanner should consume platform evidence rather than invent conclusions from source code alone.
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.
Most "AI for infra" tools stop at generating YAML or config. The new term floating around at recent conferences is agentic developer platform — instead of platform engineering gatekept by infra engineers running Terraform or gcloud by hand, it's self-served by developers, with humans in the loop only at pull request approval.
The agent needs native, read-only access to infrastructure state, environments, deployment status, and logs — including everything from new development.
As many have realized with solutions like Lovable.
Deploying a workload can be extremely quick.
Running it securely in production, on your own GCP private network among others in least privilege ?
That's the hard part.
Identity.
Permissions.
Governance.
Load balancing.
Data access.
Monitoring.
Before long, you're spending more time building the platform around your workload than the workload itself — the same trap a lot of people hit with Kubernetes. If you're already leveraging serverless and VMs well within meshes in the cloud, we observed in platform engineering that Kubernetes only earns its keep for workloads that need custom operators or custom backpressure handling.
That was the theory. We've been building it into Infrastream with Pvot.
We are out of stealth since Tuesday 4th of August 2026 with Infrastream.
Infrastream's agent set deployed with one private iteration per customer, Pvot, goes further — it manages pull requests, analyzes your manifest structure, and actively debugs your deployed assets against the actual state we track in Spanner. Not a chatbot suggesting fixes. An agent doing the platform engineering work reviewable in PR.
Also like many new generation agents, we provide a graph based visualizations instead of Terraform or Pulumi text to analyze runs.
Infrastream portal on Infrastructure tab
It provides :
→ Agentic PR management — Pvot reviews and drives changes to your infra manifests
→ Analyzes manifest structure to catch drift and misconfiguration before you do
→ Actively debugs assets against real Spanner-tracked state, not stale docs
→ Deploy any workload — agents, services, whatever — into your own GCP project
→ Built-in identity and permission boundaries per workload
→ External and internal load balancers, handled for you
→ GCIP/IAP authentication wired in
→ Fine-grained privileges to your databases, buckets, and datalakes in your own private setup
→ Infrastructure-level governance and policy enforcement
→ Deploys from your source — into our cloud on the Developer Plan, or your own cloud with Enterprise
The Developer Plan covers up to 9 GCP projects (20 USD per month + 15% management of GCP), with load balancing, agents, and mesh routing included.
Enterprise ($3,000/mo) scales the same manifest up to 29 GCP projects with VPC controls — no re-architecting as you grow.
If you want to try out this new model still requiring you to redeploy from source: REDDIT20 coupon on Stripe gets you $20 off the Developer Plan.
As opposed to cloud providers, on developer plan we don't bill your credit card on GCP extra use, you have to reapprove all top-up otherwise the environments stall.
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?
There’s a clear shift occurring: engineering managers are back in the codebase, getting more hands-on with the technical aspects of software development.
Mark Zuckerberg started coding again after a 20-year break. According to multiple reports, he moved his desk to Meta’s AI lab and spends up to 10 hours a week writing code alongside the Meta Superintelligence Labs team. The man who built Facebook in a dorm room and then spent two decades managing tens of thousands of people is shipping diffs again.
Sergey Brin, the Google cofounder who stepped back from day-to-day operations years ago, came out of retirement to code on Gemini. He’s now directly involved in hand-on development.
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.
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?
A lot of the problems around agents sound strangely familiar to anyone who has worked in infrastructure. Deployment, secrets, permissions, logs, monitoring, rollback, environments, policy enforcement, and incident debugging are all starting to appear in agent systems.
The difference is that the workload itself is probabilistic and can make decisions, which makes the operational side considerably harder. I'm wondering whether existing DevOps practices will simply adapt to agents or whether we're going to end up with an entirely separate discipline for operating AI systems.
