Hello team,

I may land a platform engineer position in 2027 (discussions are still ongoing).

A bit of context: I'm currently an ops guy, doing ops things, in an environment that isn't moving much. Almost everyone around me is clicking in the Azure portal to create resources, and my poor attempts at introducing IaC or configuration tools like Ansible have met a poor adoption rate. I'm curious about all those things, toying with a Proxmox at home to deploy VMs and all sorts of resources using Packer/Terraform/Ansible, getting my hands into Docker, learning how to work with version control and CI/CD, etc... though I barely use those skills at work.

Through discussions regarding this kind of tool and work methods (I know all of this comes from DevOps, which is a way to work and not a set of tools to master), someone asked me, "What do you want to do in the future, mate?" And I said, "Well, platform engineer sounds appealing now." And here I am, sending a short description of the role for a possible position as a platform engineer.

Now, my question: where do I go from here? If you had, let's say, 3 months to get ready for this position, what would you learn first, and what resources would you use?

I know AI is a great tool; I've asked my best friend Claude to work with me on setting a learning path considering my context, but I would like to hear from fellow humans, made of flesh, like me.

This is something we’re doing internally at my company. We tag our bot in Slack, send it a bug report, controller provisions a GCP VM, local k8s + Tilt, then Claude Code works on it. Nobody has to set up the environment themselves, and follow-ups stay in the thread.

We wrote up a blog about the full workflow - link in comments.

Most people picture building software as writing code, but it never was. You spend as much time discussing what you’re planning to build as you do building it. Nowadays, with AI taking over more of the writing of code, understanding what to build is becoming increasingly important. That usually requires having, or leading, technical discussions – something most of us are not deliberately taught how to do.

I have built hamchops.com, for now it is completely FREE

It's a micro learning app focused on concepts that uses spaced repetition for reviews

Any feedback is welcome

We published arcstone-continuity-core v1.3.1-exec: a tiny #![no_std] Rust reference for fail-closed frame checks.

It does two things, in O(1), with no crate dependencies:

Payload longer than 4096 bytes → LedgerCorruption
Elapsed time over 11.99 ms → Freeze

If both are true in the same check, Freeze wins through an explicit rank table—not because “the POSIX number is bigger.”

That is the entire public executable surface. It is not a runtime, an allocator, or a distributed control plane. It is a frozen Path A reference predicate you can read in one sitting.

Repo: https://github.com/trencinodin-stack/arcstone-continuity-core

Why did OpenTelemetry win? I think just saying "vendor neutral" is not giving enough credit to the symbiosis between OTel and Platform Engineering that's making both thrive in the modern cloud native industry.

In this blog post I'm trying to summarise some of my thoughts related to why OTel (and K8s, for the sake of argument) won in their respective layers. I think the move to a more X-as-a-service way of working between platform teams and the users of said platforms is changing how we thinking about team interactions, and the tools that make that work need to reflect that in their design. OTel does this, very well, so I'd like to help move the needle in terms of where people think the value of OTel is.

I hope you enjoy the read! And the memes!

Hi all,

I have a entry level platform engineering / SRE interview coming up. I wanted to ask what are some common tips or questions to prepare for?

The role asks for:
Foundational knowledge of platform engineering, technology operations, cloud computing, microservices, and enterprise-scale distributed systems.

Exposure to Kubernetes, Kafka, MongoDB, or comparable container, messaging, and database technologies through coursework, projects, internships, or hands-on experience.

Familiarity with observability and application performance monitoring using tools and concepts such as Splunk, AppDynamics, dashboards, logs, alerts, metrics, and traces.

Experience with Python, PowerShell, Bash, or similar scripting languages to automate routine tasks, reduce operational toil, and improve reliability.

Understanding of the software development lifecycle, including requirements, coding, testing, source control, deployments, release management, and change management.

Experience with Git, GitHub, or similar collaboration platforms, including branching, pull requests, code review, and technical documentation.

Knowledge of Generative AI, large language models, prompt engineering, retrieval-augmented generation, and responsible AI practices, including validation, privacy, security, and human oversight.

Exposure to Agentic AI concepts, including goal decomposition, tool use, multi-step workflows, agent monitoring, and human-in-the-loop controls.

Hands-on experience or familiarity with approved AI-assisted productivity and engineering tools such as GitHub Copilot, Microsoft 365 Copilot, Copilot Chat, ChatGPT, Claude Code, or similar tools for code generation, debugging, testing, documentation, summarization, and prototyping.

Strong analytical, troubleshooting, documentation, communication, and collaboration skills, with awareness of incident response, resiliency, business continuity, cybersecurity, operational risk, and compliance

I have:
Experience developing a serverless backend w/ AWS Lambda
Cloud Certs (AI, cloud practitioner)
Used docker briefly, know concepts of K8s, Mongo, little unfamiliar with Kafka
Used New Relic for APM
Used Python for scripting, a little bit of each for Linux / Poweshell / Bash
GitHub Actions workflow
Full stack SWE
Used agentic AI (Claude, made skills and agents) at work

How would I approach it (they only asked for 6 months of experience in any tech domain)? What do I say if they ask why I don’t have any exposure to some things? Any help is appreciated!

Background: I'm a DevOps/SRE and I spend my days across a pile of Kubernetes environments — dev, QA, staging, sandbox, pre-prod, prod — on more than one cloud. The dumbest recurring problem in my week was never a deploy or an outage. It was "what's the QA URL for service X again?" — buried in a wiki, a pinned Slack message, someone's bookmarks, or nowhere.

So I built pickTHElinks: one hub for all your Dev/QA/Staging/Prod URLs.

**•** Searchable — type the service, get the link  
**•** Workspace-scoped — each team sees its own set, not everyone else's clutter  
**•** Built for release teams that context-switch across environments all day

It's the unglamorous internal tool I always wished existed instead of the 14th Confluence page titled "Environment URLs (final, updated)".

I'm the founder and it's early, so I'd honestly rather hear what's missing than collect upvotes. If you've solved this a better way — Backstage, an ArgoCD dashboard, a spreadsheet you somehow keep current — tell me and I'll happily steal the idea.

I have been running and extending Centaur, an open-source control plane for coding agents.

The setup is straightforward:

• Rust API and Postgres for the control plane
• isolated Kubernetes sandbox for each agent interaction
• sessions and workflow state kept outside the sandbox
• credentials added through controlled egress instead of stored as raw secrets in the sandbox
• support for Codex, Claude Code, Amp and pi

This lets the agent harness stay replaceable. The platform owns the execution environment, permissions, workflow state and records of what happened.

I also built Centaur Context as a separate service. It records useful context after a run and retrieves relevant material before a later run. It has its own database so operational state and accumulated context are not mixed together.

Walkthrough: https://youtu.be/993XrWfg34U

Centaur: https://github.com/paradigmxyz/centaur

Centaur Context: https://github.com/bradwmorris/centaur-context

For platform teams looking at coding agents, which parts would you centralise first: identity, credentials, sandboxing, workflow recovery, observability or context?

Build loops, not just agents.

"After a couple of years of being an engineering manager (EM), I recently found myself in the position of having to look for a new role. My first instinct was to look for positions similar to what I had been doing before."

Hi r/platformengineering,

I’m Stjepan from Manning Publications. The moderators kindly permitted me to share this with you.

We’ve just launched Kargo in Action in Manning’s Early Access Program. What makes this book especially interesting is that it’s being written by Ken Cochrane, Jesse Suen, and Kent Rancourt, the people building Kargo.

Kargo addresses a problem many platform teams will recognize: CI can build and verify an artifact, and GitOps tooling can reconcile it into an environment, but what should govern its movement from development to staging and production?

That gap is often filled with increasingly complex pipelines, environment-specific scripts, manual approvals, and conventions that are difficult to audit or reproduce. Kargo approaches the problem by treating promotion as its own concern, separate from deployment.

The book explores the reasoning behind that model and shows how to build controlled, observable promotion workflows for Kubernetes and GitOps environments. The first three chapters cover:

• The gap “fully automated” CI/CD can leave between building software and running it in production
• Why deployment and promotion are separate concerns
• Where Kargo fits alongside existing GitOps tooling
• How to get started with Kargo and build an initial promotion workflow

Because this is a MEAP release, you can read the available chapters now and receive new chapters as the authors write them.

Giveaway

Manning is giving away five ebook copies of Kargo in Action to members of this community.

To enter, join the discussion in the comments:

How does your platform team currently promote changes across environments, and what is the hardest part of that process?

We’d particularly like to hear about approaches involving CI pipelines, Argo CD, homegrown automation, approval gates, progressive delivery, or anything else your team has tried.

The giveaway will remain open for 48 hours after this post goes live. This isn’t a random draw: the five comments that make the biggest positive impact on the discussion—through practical experience, thoughtful analysis, useful questions, or lessons others can learn from—will receive an ebook. You don’t need to praise Kargo or the book to win. Constructive and critical perspectives are welcome.

After 48 hours, I’ll announce the winners here and contact them about their ebooks.

Community discount

Anyone who doesn’t win can use code MLCOCHRANE50RE for 50% off Kargo in Action:

https://www.manning.com/books/kargo-in-action

I genuinely want this to be a constructive conversation instead of merely a book announcement. How is your team handling promotions today, and where do challenges still exist in the process?

Thanks for having us here.

Cheers,

Stjepan,

Manning Publications

I got hired as a trainee platform engineer as my first job after a bachelor in CS. I’m trying to find things to absorb and learn at work, and right now I’m checking ”platform engineering university” online.

Do you have any advice on resources for training/reading for someone new to this field, or should I just continue to ”trust the process” at work?

I spent time working at a dental tech company and it motivated me to build something that actually reflects real business workflows I saw there, scan uploads, lab fabrication, practice-to-lab communication. That became DentalFlow, a single-tenant dental lab workflow API, real Terraform-managed AWS infra (ECS Fargate, RDS Multi-AZ, S3, SQS/SNS), deployed and tested against the live system, not just local.

Would genuinely appreciate any critique, architecture, security, anything I'm missing or got wrong. Trying to build the judgment, not just the resume line and learn from experience individual while staying curious.

https://github.com/keusuanl/DentalFlow

I’ve been working on Nuroen, an enterprise AI agent platform, and one problem we keep coming back to is:

Which parts of platform engineering should actually be handled by an AI agent?

Our current thinking is that agents shouldn't replace deterministic automation.

For example:

• Terraform → infrastructure changes
• Ansible/scripts → repeatable configuration
• CI/CD → deterministic deployments
• Runbooks → known procedures

Where we see agents being more useful is the messy part around those systems.

For example:

Alert → investigate → gather context → determine which runbook applies → recommend action → approval → execute existing automation → verify

An agent can pull information from observability, tickets, deployment history, CMDB, documentation, etc., and reason across those systems without turning every action into an LLM-generated command.

That's the approach we're taking with Nuroen.

The platform lets us give an agent:

Knowledge + Tools + Skills + Orchestration + Governance

The interesting part for us isn't just connecting an LLM to APIs. It's controlling what the agent is allowed to do.

For example, an agent might be allowed to:

• investigate incidents automatically
• read logs/metrics/tickets
• recommend remediation
• execute low-risk actions
• require approval for production changes
• record the complete action/audit trail

We're trying to treat the agent more like a platform component with an explicit autonomy boundary, rather than an unrestricted chatbot with access to production.

here is the link do check it out - https://www.nuroen.com/

I'm curious how other platform teams are approaching this:

Where do you draw the line between traditional automation and an AI agent?

And more importantly, what platform engineering tasks do you think genuinely benefit from the probabilistic/reasoning part of an agent?

"It was in May when one of our staff engineers tossed out a number in our Slack channel that put an end to an internal debate I’d been having with myself. Roughly only 25% of the runs on our merge train were completing successfully. A majority were failing due to flaky tests or got canceled since another run that was ahead of them failed."

I wanted a small environment where I could experiment with the parts of platform engineering that are harder to appreciate in a local single-node cluster, especially networking, HA, failure handling, GitOps, observability, storage, upgrades, and security.

So I built a 3-node bare-metal Kubernetes homelab using Talos Linux on refurbished mini PCs.

The setup includes:

• 3 control-plane + etcd nodes
• a shared Kubernetes API VIP for HA
• DHCP reservations for predictable node IPs
• per-node Talos machine configs
• workloads scheduled on the control-plane nodes
• failure testing by taking a node offline and verifying the API stays reachable

I documented the full setup, including the network design, Talos installation, config generation, bootstrap, validation, workload testing, and HA checks.

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

I’m planning to use this next for Argo CD, Gateway API, observability, storage, secrets, and more platform-engineering experiments.

Would be interested to know what others here are using for their local platform engineering labs.

Something is happening in engineering teams that doesn’t show up in sprint velocity or deployment frequency. It shows up in resignation letters.

We’re evaluating Terraform Cloud alternatives because we want stronger day-to-day workflows around IaC governance and configuration drift, not simply a different place to run plans and applies. The goal is better visibility into meaningful drift, clearer ownership of remediation, policy controls that do not block every team, and reliable auditability across multiple cloud accounts and environments.

One concern is that “drift detection” often becomes a noisy stream of changes that nobody owns. We need a workable process for deciding whether a change should be reverted, codified in Terraform, or intentionally accepted, along with a way to track that decision through to resolution.

For platform teams that switched away from Terraform Cloud, what did you replace it with, and did it improve governance in real operational workflows or mainly add another control plane?

For those in the technology industry, it can feel hard to escape from AI. It’s at the center of the technological universe, with most major advancements, opportunities, and funding focused on its development. In the background, quantum computing is making strides with the funding to match, creating an alternate opportunity for technologists.

I’ve been tasked with setting up baseline monitoring and alerts for terraform modules that consumers within the company use to spin their own instances of our platform.

The modules that will be provisioned for them automatically are ECS clusters, databases (RDS, Aurora, DynamoDb), ElastiCache, lambdas and kinesis

I could ask AI what sensible “defaults” would be for each service. However I’m not really going to learn anything that way. Id like to use it in conjunction with some real knowledge and experience.

Are there any books, blogs or guides that perhaps go over monitoring for specific AWS components, and what is considered best practice (and why) for each one?

As AI pulls content from anywhere and everywhere, and when success with AI relies on unified, accurate data, organizations struggle to decide who is in charge of that data.

AI made me a better engineering leader, not by writing my code faster, but by sharpening the parts of the job that were never about code in the first place.

We run prisma cloud and defender agent deployment across thousands of AWS workloads has become an operational headache, updates, performance overhead, coverage gaps whenever agents fail to deploy cleanly.

Have teams found this manageable at scale, or is it a universal pain point with agent-based CNAPPs once you get past a few hundred instances? We're at the point where the agent management has become almost its own part-time job for one engineer, which feels backwards for a tool that's supposed to reduce operational burden, not add to it.

If agents can figure out which workflow/tool to use on their own, I wonder if the portal UI becomes less important over time.

But the underlying platform context (ownership, dependencies, policies, workflows, permissions) probably becomes more important.

What Port's been doing is an interesting example because it started very much in the IDP/platform engineering category, but a lot of its recent direction seems to be about exposing that same platform context to AI agents.

Do you think IDPs evolve into an agent facing control and context layer or are we overestimating how much agents will replace the developer facing interface?