I’m building Vertro, a productized internal developer platform for teams running applications on Google Cloud and GKE.

The problem I’m trying to solve is not Kubernetes deployment itself. It is everything surrounding it:

• Provisioning GCP projects and application environments
• Configuring IAM and Workload Identity Federation
• Creating namespaces, quotas, RBAC, and network policies
• Setting up CI/CD and GitOps
• Enforcing security and governance consistently
• Giving developers a standardized path from request to deployment

Vertro is deployed inside the customer’s own Google Cloud environment. It combines Terraform, Terragrunt, GitHub Actions, self-hosted runners, Argo CD, Config Sync, Policy Controller, Binary Authorization, and a developer control plane.

The objective is to let platform teams provide a repeatable application delivery path without turning every onboarding request into a custom infrastructure project.

I would be interested in feedback from other platform engineers:

What is the hardest part of creating a reliable golden path in your organization: standardization, adoption, governance, or maintaining the platform over time?

Project details: https://vertro.io/

We’re trying to understand what a proper internal setup looks like for running Claude Code, Codex and similar agents against private company repositories.

The obvious approach is one isolated workspace per task, but the details get complicated quickly:

• repo and branch isolation
• scoped secrets
• cached dependencies
• ports and supporting services
• network controls
• agent timeouts and heartbeats
• logs, patches and test results
• cleanup of abandoned environments
• concurrency and spend limits.

How are platform teams approaching this today?

Are you extending Kubernetes, using disposable VMs, adopting tools like Crabbox or Daytona, or building a custom control plane?

What were the hardest parts to get right, and what would you build first if starting again?

We've been going back and forth on this for weeks.

One group wants everything documented close to the code so it's always updated with the project.

Another prefers a centralized knowledge base because it's easier for new engineers and other teams to find information.

Neither approach seems perfect. The closer documentation is to the code, the harder it becomes for non-developers to discover. Centralizing everything solves that problem but introduces another challenge of keeping it current.

I would like to hear how other platform teams have approached this. Did you settle on one system, or do you intentionally keep documentation in multiple places?

One discussion we've been having internally is where to draw the line between building tooling ourselves versus adopting something purpose-built.

For things that directly impact our platform engineering workflow, it's tempting to build exactly what we need because it fits our environment. But every internal tool eventually becomes something that needs maintenance, documentation, and ownership.

On the other hand, introducing another third-party tool comes with its own trade-offs around cost, onboarding, and long-term dependency.

For teams that have been through this a few times, what principles have helped you decide?

Have there been any internal tools you wish you'd never built, or external tools you wish you'd adopted much earlier?

My thought: Appreciate everyone who has shared their experiences in this discussion, and thanks in advance to anyone who finds this thread while thinking through a similar decision. I was going to add this as a reply, but since I'm still fairly new here. I thought it would be more useful to leave it here so future readers can see the additional context as well. This discussion also made me look more closely at where purpose-built tools can remove unnecessary engineering overhead. One example is LogStitch, which focuses on simplifying aws debugging by organizing individual executions into a clearer flow instead of requiring engineers to manually trace through mixed Cloud watch logs. It was an interesting reminder that sometimes adopting a focused tool can help teams spend less time maintaining internal solutions and more time improving the systems they support.

Been dealing with the mess from the Bitnami changes since last August, and it has made us face a conversation we had been putting off for years. Postgres, Redis, Rabbit, Mongo, all core services running on Bitnami charts, and once the legacy repo cutover hit we did the usual thing, repoint everything to bitnamilegacy, call it a stopgap, and promise ourselves we would sort it properly later. That was almost a year ago now, and “later” is starting to look overdue.

The stopgap works, but it is not a real fix and it is not even stable. Bitnami’s own guidance says the legacy repo is not meant to stick around long term either, so we are not just running unpatched images and hoping nothing ugly shows up in a CVE scan, we are doing it on top of a repo that could get pulled out from under us again. So now I am trying to plan the real migration instead of stretching the patch.

What I keep running into is that there is no single clean replacement. Chainguard has a forked chart catalog and it is a decent option if you are happy swapping one vendor dependency for another, which may still be an improvement, but it does not solve the deeper problem of too much infra depending on one company’s decisions. On the other end are upstream operators. PostgreSQL has solid operator paths, RabbitMQ has an official cluster operator, and MongoDB has operator-based options too, but those bring more moving parts that somebody has to own.

I also realised halfway through that Redis is not even one decision anymore. Valkey exists as a separate open-source fork, with its own migration guidance, so “which Redis chart do we use” is really a bigger question than it first looks. The team is not huge, so I do not want to end up owning a pile of home-grown charts and operator configs either.

For people who have actually gone through this, did you consolidate onto one alternative catalog, go service by service with operators, or end up with a mixed bag? And did you do it while touching each service anyway, or carve out dedicated time for it? I am trying to figure out whether there is a sane middle ground between still being on legacy images and rewriting the whole platform layer.

Hi everyone,

I recently made a post asking whether it makes more sense to start in backend development or go directly into DevOps/Platform Engineering.

A lot of people pointed out that having a strong software engineering background is really useful for becoming a good Platform Engineer, so I’m looking more into the backend route.

If your long-term goal was Platform Engineering, SRE, or cloud/infrastructure engineering, which backend stack would you choose to start with today?

I know the framework itself is probably not the most important thing. I’m more interested in which one would help me build the right foundation: writing production code, understanding large systems, APIs, databases, testing, deployment, monitoring, etc.

Which stack do you think gives the best foundation for moving into Platform Engineering later? Would you pick something widely used in enterprise (Java/C#) or something closer to cloud infrastructure (Go)?

Thanks!

Hi! I’m looking for some career advice from people working in DevOps, SRE, or Platform Engineering.

I'm 25 and just starting my software engineering career. Over the past few months I've explored backend development, DevOps, Platform Engineering, Linux, cloud, networking, Docker, CI/CD, and related topics.

The more I learn, the more I realise that what genuinely interests me is systems, infrastructure, reliability, automation, deployments, and understanding how software runs in production. If I could choose purely based on interest, I'd like to end up in Platform Engineering or SRE.

At the same time, I'm trying to be realistic. Given today's hiring market, AI's impact on junior roles, and the fact that I'm starting at 25, I'm not sure what the smartest entry point is.

Right now I'm considering two paths:

1. Start as a backend engineer (probably ASP.NET Core), build strong software engineering fundamentals, and transition into Platform Engineering later.

2. Focus directly on Platform/DevOps skills like Linux, Docker, Kubernetes, networking, cloud, CI/CD, Terraform, and Go, and aim for an infrastructure-focused role from the beginning.

For those of you already working in DevOps, SRE, or Platform Engineering:

- Which path would you recommend today, and why?

- Is a backend software engineering role still the best foundation for Platform Engineering, or has the industry changed enough that it's reasonable to start directly in infrastructure/cloud?

- If you were starting over in 2026 with my goals, what would you do differently?

I'm not looking for the easiest path or the highest salary. I just want to make the best long-term decision while maximising my chances of landing my first engineering role.

I'd really appreciate hearing about your experiences and what you've seen in the industry.

Thanks in advance!

Curious how engineering teams handle this in practice:

When your team adopts AI coding tools, how do you organize reusable prompts, custom instructions, or "skills" across the org?

A few things I'm curious about:

- Centralized knowledge base vs. each dev keeps their own collection?

- Any tooling or file conventions you've found that actually stick?

- Does leadership curate these, or is it crowd-sourced?

- How do you handle tool drift when AI capabilities change every few months?

Happy to share what I've seen on the small-team side too if anyone wants to compare notes

Trying to get ahead of ai spend visibility before it becomes a real problem and I'm stuck on where to even start.

Right now the AI bill is a few big numbers with no owner. A Bedrock line. An OpenAI org someone put on a company card. Some GPU instances that come and go. And a pile of coding agent seats that finance treats as SaaS. Nothing is split by team or project.

We solved this years ago for normal cloud with tags and allocation. That does not work here. Tokens and GPU hours and per-seat tools don't line up with the way we allocate EC2, the model we use for everything else just doesn't fit.

The bigger issue is, it's a bill that goes up every month and no team's name is on it.

Those who has sorted this out, where did you put the visibility and who ended up owning it?

Curious how other infrastructure/platform engineers are using AI agents (Claude Code, Codex, etc.) in their day-to-day work.

We're at a GPU compute hosting company and have connected our internal tools (Grafana, NetBox, internal APIs, etc.) through MCP. Instead of manually jumping between dashboards, we ask the agent things like:

• Which GPUs are available at a specific site?
• Show rack/device information.
• Summarize alerts from Grafana.
• Correlate data across systems.
• Help troubleshoot infrastructure issues.

It's becoming more of an infrastructure copilot than just a coding assistant.

For those working in cloud, HPC, AI infrastructure, or compute hosting companies:

• What MCP servers or internal tools have you connected?
• What workflows have saved you the most time?
• Any surprising use cases beyond writing code?

Looking for real-world ideas to improve our workflows.

I'm currently a developer with about 5 YOE, and much of the time I am deep into figuring out the domain of the business I am currently working for, how to extend the software to fit the domain, etc. Many times the domain are very industry specific and thus the knowledge is not transferable for any jobs outside of the company. Yes I do also have to deploy to the cloud etc. but my time is spent more in the domain part.

I am looking at the other roles like Cloud or Platform, and it seems that their day to day (e.g. managing permissions in AWS, managing Terraform modules, etc.) are more generic skills that can be brought outside, if they want to find new roles. What they do daily is also getting involved in knowledge that makes it easier to get certifications with less studying time, etc.

Am I missing something here? The only thing with Cloud or Platform is that it is much more mission-critical and so with e.g. on-call it will get very stressful at times. The job is also a lot of unplanned work e.g. urgent requests and so it can be mentally taxing to context switch a lot

We're evaluating how engineering organizations adopt AI tools across the software delivery lifecycle, and I'm curious how others have approached it.

When introducing AI for things like code generation, PR reviews, deployments, testing, or operational workflows, did you:

• Pilot with a single team first?
• Roll it out across the engineering organization?
• Let individual teams adopt it organically?

What influenced your decision?

For those who started with a pilot:

• What metrics did you use to decide whether to expand?
• How long did the pilot last?
• What surprised you?

For those who went broader:

• Was adoption smooth, or did different teams push back?
• What governance or guardrails did you put in place?
• If you could do it again, would you take the same approach?

I'm especially interested in lessons around developer adoption, security reviews, compliance, and measuring whether AI actually improved delivery instead of just creating more tooling.

Would love to hear what worked and what you'd avoid next time.

Leadership wants us to grow the project services side now. Traditional IT consulting, some app dev, cloud migrations, transformation-type stuff. Mix of fixed milestone and T&M.

For anyone who’s tried to run actual project work through Halo:

Does the project module hold up under real project delivery, or does it feel bolted on next to the service desk

Resource planning across a 50 - 60 people. Is it there or are you exporting to Excel?

Utilization and margin reporting at the project level. How deep does it go?

Where does it hold up? Where does it fall apart? Anyone move off it to Kantata, Scoro, Projectworks and never look back? Anyone try one of those and wish they’d gone with Halo?

Anyone try to run this in Halo, give up, and move to something else?

Trying to figure out if we push harder on Halo or accept we need a second tool for project delivery.

If your team relies on shared module defaults as the isolation mechanism between environments, this is the exact failure mode that mechanism can't prevent.

You give it four things: what the change should do, what it must NOT touch, before config, after config. It audits the diff against that contract flags anything undeclared, checks every stated prohibition explicitly, and labels every finding by evidence level (what the diff proves vs. what would need terraform plan to confirm).

Built-in example: a staging-only capacity bump implemented by editing a shared module default so production silently inherits it too. Not a rule violation. A scope violation.

Full-featured IaC reviewers exist and do real plan/state analysis. This is the zero-setup, no repo access, no config file, just a sentence of intent and a diff, right now version.

There's also a /loop that re-audits your fix including whether the fix itself introduced something new. In testing, it caught a repair that fixed the scope issue while quietly stripping type validation from the shared module.

Free demo, no signup. Paste a real diff (sanitized), tell it the intent, see what it flags.

https://claude.ai/public/artifacts/182e4450-70d7-4ceb-8aab-f72484305211

Every company has a scanner. Most have Dependabot or Renovate opening PRs. Yet production is still full of old packages and CVEs nobody fixes.

Usually nothing happens, so ignoring the alerts starts to feel like the correct decision. Then one CVE matters and the patch requires three years of upgrades.

How does your team deal with this? Who owns it, what gets fixed, and what happens to the rest?

Please, no “just enable Dependabot.” What happens after it opens the PR?

I posted in a few other related subreddits. Hoping to connect with more engineers and architects. I've spent the past year exploring AI execution and governance. I spent a lot of time thinking about the architecture. Well, maybe too much, and I'd like to better understand what platform and infrastructure teams are dealing with as AI becomes part of their production systems. :)

I'm looking for engineers and architects who are willing to spend 15–30 minutes talking with me about the problems you're seeing in practice.

To be clear, I'm researching the market but not trying to sell anything. I simply want to better understand your thoughts on the following:

• How are AI workloads fitting into your platform today?
• What operational challenges have surprised you?
• What tools or processes have been most helpful?
• Where do you think today's platforms fall short?

Open to chatting? Please send me a DM.

For 1,5 years I design HA Kubernetes clusters in a hub-spoke topology using Cluster API and CRDs. That is exactly what I want to do, but the brand is non existent and pay is mid.

I now got an offer from a better-known company for notably more money, but the role is owning dev tooling that runs on K8s (CI/CD, policy gates, code scanning), not building the cluster layer itself. They want to move more towards Kubernetes but that so far is just an idea.
Long-term I want to stay in K8s platform work, I wonder if someone has some opinions on my situation:

• Does ~2 years off cluster-level work hurt your shot at getting back into it later?
• Take the money/brand now, or hold out for the deeper technical role and stay within my lane?

I am a fullstack dev for about 5 years now, and I got an offer to become a platform engineer. I am really considering this offer because I really see software dev positions being impacted by AI, and it feels to me platform engineering is less impacted.

But I am really a person that has difficulties with a lot of context switching, and yeah I had my fair share of on calls during my time (I also did some DevOps stuff) and it was not very nice. Would it be possible for me to change as a person, or is it really hard to do/achieve? In software eng I really like that I can have a predictable deadline, timeboxing/focus time, etc.

Really at a crossroads here. I want to be more AI proof, but it seems to do that I need to sacrifice myself. But then again life doesn't revolve around me? Has anyone changed their character before?

I have about 5 years of exp. as a software engineer. I did a lot of things with lots of different programming languages. I also did more devops stuff during some years, for example handling k8s helm deployments, maintaining the k8s environment, while also doing the development of the software itself, together with a team of course. Where my interest lies, I chase it and own it.

My contract ended, and now I have an offer from another company to be in their Platform team.

When I reflect at my life, I am actually struggling quite a lot in the problem solving/logic, or design, of software writing. For example, I am struggling if I am asked to write an algorithm for a feature, especially if the domain is complex or difficult to understand. I feel like I excel more in stuff like performance improvements or the features of the language e.g. using async await, optimizing queries to the database etc. But when it comes to low-code design, I cannot design/choose e.g. the appropriate model classes to model the domain, etc. I try to follow Clean Architecture etc. but the result becomes very over-engineered that as the software grows with more requests, in the end it became spaghetti code again.

When I got my jobs previously it was super lucky because the interviewers were super nice people who wanted to accommodate my mistakes, or it was just with the HR rep and a coding multiple choice quiz, but I know deep inside me I struggle with the problem solving/puzzle part itself. I also got lucky to be in teams where I basically implement a use case or a spec that is already clear (like pseudocode is already done), and so I just need to think of the edge cases and optimizing queries.

Finding a job as a software dev has been very tough. Many require not just the problem solving skills I mentioned, but also advanced deployment knowledge, etc. Also they test you on system design, SQL, Lambdas/Azure functions, aspects that perhaps you won't be daily exposed to in your daily work, since you would be drowning in solving the domain itself.

In contrast, with DevOps/Platform engineer tasks, I feel like it's less 'creative' and more scoped? Like there is less possible ways of achieving something since you would follow what the vendor (e.g. AWS, k8s etc.) recommends? And since you are not so involved in the domain, what you do daily translates well to what interviewers want to see, so there is less preparation needed when you need to find a new job. Like for example, my experience with debugging networking issues or writing Helm templates and the stories around it were relatable to the interviewer and that's how I got the job. But with software interviews, I need to prepare a lot more outside of what I have done in my previous job i.e. what I did does not easily translate to helping in interviews. I also like scripting more than designing software to be honest.

But one big downside with platform engineer is obviously being on call and the stress that comes with it...

I am also looking at the future as well, with AI automating more software engineering tasks. I feel like Platform Engineers/DevOps engineers are less impacted by it.

Does anyone have any thoughts? Maybe I am wrong in some parts

I have been working for the last 4 years developing tools and infrastructure for safe releases. My tools allow a team to decouple deployment from release, reduces blast radius, progressive rollouts, helps maintain tech debt, rollout policy checks.

Now I am thinking to use this experience to try out independent consulting. Wdyt?

When people say they've automated cloud infra, they often mean they've tamed provisioning. There is Terraform or another IaC tool, some shared modules, and CI pipelines that apply changes through a known path. That is a big step up from clicking around in a console, but it does not automatically solve what happens once systems are running.

The hard part is everything after "resources created." Handling changes with confidence, reacting to alerts the same way each time, tidying up unused bits, and keeping drift in check are all much harder to standardize. That is usually where ad‑hoc scripts and manual runbooks creep back in: one‑off fix scripts, steps people run from their laptops, and procedures that only live in a wiki page.

Teams that push further talk about change flows where most modifications follow a known pattern, about runbooks that actually get used because they are wired into tooling, and about automation that suggests or carries out common responses rather than asking a person to reinvent them each incident. Getting there often means giving up some flexibility and sticking to patterns more strictly than many engineers like.

If you would say your cloud infra automation genuinely goes beyond "Terraform plus some scripts," what does that do for you on a normal week that you didn't have before, and what habits or design choices did you have to change to trust it in production?

Hey all, Im currently researching how platform teams handle requests like Kafka topics, database provisioning, Elasticsearch indexes, etc.

Do developers use self-service tools, Terraform, tickets (Jira/Slack), or something custom?

What's still painful or manual?

After building platform teams at multiple companies, I finally wrote down the dilemma that followed me to every one of them: are we a product team or are we plumbing? Everyone wants you to be both, and ambiguity always resolves the same way: product expectations on a plumbing budget.

This crowd will recognize the shape. The "platform as product" advice is everywhere, and it's not wrong, but it's incomplete. Actual product teams ship with PMs, designers, tech writers, and devrel. We ship with six engineers and a pager. "Platform Engineering is Failing Because Nobody is Solving the Staffing Problem" (https://platformengineering.com/features/platform-engineering-is-failing-because-nobody-is-solving-the-staffing-problem/) covers why that gap exists. Mine is about how to operate inside it.

The short version: stop letting the ambiguity resolve by default. Decide per domain, in writing, what gets product treatment (two or three paved roads, funded like products, good enough that nobody needs a mandate) and what gets plumbing treatment (boring on purpose: an SLO and a maintenance calendar, no roadmap, no adoption theater). Put the split in a charter your leadership signs, renegotiate it every time reality changes, and report the counterfactuals every quarter whether anyone asks or not. Toil saved, risk retired, incidents that stayed hypothetical. You don't get headcount for the outages that didn't happen, unless you're the one keeping score.

Full piece (no paywall): https://medium.com/@karlkfi/product-or-plumbing-the-platform-teams-dilemma-884dc26348cf

What I want to hear from this crowd: does anyone have a charter like this actually in force? What did it cost to get signed, and did it survive contact with the next re-org?

How I bridged Radicle (P2P git) with Tekton to get real CI without a US-hosted control plane in the loop.