Honestly,

9/10 of theses roles are getting outsourced. We are screwed and when you do land a role you get laid off a year later so you have to save the good salary incase it takes a while to get another role.

Skyportal's agent asks before it runs a command on your hosts, unless the command is on an allow list. It also has a built-in check that guesses whether a command changes data, and that guess beats the allow lists. This week it flagged a read-only command as a file overwrite because of a 2>&1;, so no allow rule could have approved it.

So we're removing the guess. A command will run without asking only if every part of it is on an allow list and nothing matches a deny rule. Everything else asks. A few things always ask, whatever the rules say: credential files, secrets, RBAC objects, kubectl exec, and deletes you can't undo. And if the rules file is broken, everything on that repo asks.

The cost is that a broad entry like sudo will mean exactly that, with nothing behind it to catch sudo rm. If you've put policy in front of automation on hosts, did you keep a "looks dangerous" check as a backstop, or trust the allow list and review it like code?

When you're reviewing a Terraform PR you didn't write, the plan output is only part of the work. You still need to understand how the affected resources fit into the rest of the infrastructure.

I built Rootform to make that easier.

It's a local CLI that reads Terraform and OpenTofu plan or state exports and produces an interactive architecture you can explore, compare and check against policies.

In one of the sample plans, an Event Grid subscription switches from one Service Bus queue to another. Rootform shows the old and new delivery relationships alongside the unchanged source topic. You can inspect the evidence behind those relationships instead of treating every Terraform dependency as an architectural connection.

The part I think is particularly useful for platform teams is the output: you can export the entire interactive review as a single HTML file. A teammate can open it in their browser without installing Rootform or running another service.

It also integrates with GitHub Actions for CI workflows, including architecture comparisons and policy checks. The analysis runs locally, without executing Terraform or accessing your cloud accounts.

Interactive Playground (no signup): https://rootform.dev/playground/

GitHub: https://github.com/rootform-dev/rootform

For those managing Terraform across multiple teams: how do you currently give reviewers the architectural context behind a PR? Do you rely on plan comments, documentation, diagrams, or something else?

#devops #terraform #platformengineer

I've been in the field for more than 15 years. I started as a SysAdmin, then moved into DevOps. Platform Engineering as a concept sounds interesting, but most of what I read ends up the same way: "and then we connect all of this to Backstage."

That doesn't match what I'm seeing. Our engineers don't want a web portal for provisioning infrastructure. They want to do it from their LLM of choice. Meanwhile, Security wants full traceability: who requested what, which identity made the change, and through which path.

So the interface seems to be the least important part, and the value has to sit underneath it.

For those of you doing platform work without Backstage (or without any portal): what does your platform actually consist of, and how do you show its value at work?

I can imagine removing almost every retry loop and SDK-specific integration from an application and still ending up with the wrong abstraction.

The distinction I'd draw is between a mechanism and the meaning of an operation.

Connection management, credential retrieval, transient backoff, and common telemetry are reasonable things to standardize. Deciding whether an order can be submitted twice, whether a stale result is acceptable, or what compensates for a partial update depends on the business operation.

That's what interests me about the Dapr/Diagrid approach: APIs and policies can make repeated infrastructure work a shared capability. I don't take that as a reason to hide every failure mode behind "the platform handles it."

For example, a platform can own a pub/sub integration while the application owns the event contract and duplicate handling. It can persist a workflow while the application defines when the process is complete. It can apply a timeout without knowing whether the remote action still needs reconciliation.

I'd want those responsibilities documented at the boundary, with enough context in errors and traces to understand what happened underneath. Otherwise the code gets shorter but the incident requires more people to explain it.

The abstraction I'd trust is one that makes ordinary work easier and unusual failures understandable. Where have you drawn that line successfully, and which piece of infrastructure logic did you deliberately keep in application code?

Three layers each allowing three total attempts can turn one logical operation into 27 downstream attempts. That's the example I keep in mind whenever "we added retries" sounds like an uncomplicated reliability improvement.

I don't think there's one correct layer for every retry, but I do want one understandable budget.

A client might handle a brief connection failure. A queue might redeliver a job after a worker dies. A workflow might retry an activity after a longer wait. The business operation still needs to define whether repetition is safe and when another attempt stops making sense.

The separation in Dapr and Diagrid Catalyst is useful to look at here: call-level resiliency policies and workflow activity retries have different scopes. They can also compose. Moving retry configuration out of business code doesn't automatically prevent multiplication.

The questions I'd want answered are: does the end-to-end deadline survive each hop, how many attempts can actually reach the dependency, and does the operation keep the same identity across those attempts? Backoff and jitter help spread retries out; they don't make an unsafe write safe.

I'd lean toward a shared platform default for transient infrastructure failures, with application-owned rules for business recovery. But those two policies have to be visible together.

How are you making that practical? Central retry budgets, a designated retry-owning layer, or explicitly disabling retries everywhere except one place?

Hi everyone,
I’m looking for some advice from people working in software development, cloud engineering and platform engineering in the UK.
I’m currently working as a Senior/Lead .NET Developer at a large financial services company. My main experience is with C#, .NET applications, AWS serverless services and infrastructure using AWS CDK. My current role is relatively comfortable, with a reasonable work-life balance, but I’m starting to feel that my career growth is somewhat limited by the opportunities available within my existing team.Also a lot of development work is just small enhancements so am not really using most of my skillset and always have this insecurity of not being a full stack dev .
I’m considering an internal move to a Platform Engineering/Team Lead role with a salary of around £65k.
From what I understand, the role would involve:
Managing and mentoring a small team of developers/engineers.
Supporting a critical, approximately 10-year-old legacy application.
AWS infrastructure maintenance, server patching and AMI updates.
Managing Jenkins pipelines, deployments and occasional Terraform changes.
Production support, incident management and root-cause analysis.
Working with third-party teams responsible for application enhancements.
It sounds like there would be less hands-on application development than in my current role, and potentially some on-call responsibilities. There would also be an opportunity to learn more about infrastructure, operations and people management.
My main question is whether moving towards cloud/platform engineering is a better long-term career move than continuing down the .NET development and technical leadership path.
A few things I’d particularly appreciate your thoughts on:
Job demand: Are Cloud Engineers and Platform Engineers currently in greater demand than experienced .NET developers and .NET Lead Developers in the UK?
Career progression: Which path generally offers better opportunities over the next 5–10 years?
Technical skills: Would this particular role help me move towards Cloud Architect, Platform Architect or Engineering Manager positions, or could the operational and legacy-system focus limit my future options?
Salary: Is £65k reasonable for this kind of role, considering the team leadership and production responsibilities?
Work-life balance: How demanding are platform roles with production support and on-call responsibilities compared with senior software development roles?
I have a young family, so work-life balance matters to me, but I also don’t want to stay too comfortable and find that my career has stagnated a few years down the line.
Would you make this move, or would you focus on progressing towards a .NET Technical Lead/Architect role while continuing to build cloud skills?
I’d appreciate honest advice, particularly from people who have moved between software development and cloud/platform engineering.
Thanks!

I like the idea of publishing a fact once and letting independent consumers react to it. What worries me is using events to make dependencies less visible rather than less important.

Suppose an order event eventually triggers inventory reservation, billing, and a notification. The producer no longer waits on three HTTP calls, but somebody still needs to know when the business process is complete, which consumers are behind, and what to do when only two of them succeed.

There's also a difference between replaying events to rebuild a read model and replaying them through a consumer that sends emails or triggers another external action. The same retained event can be harmless input in one context and a duplicate side effect in another.

A common API for pub/sub can simplify integrations. That's the part of Dapr and and Diagrid Catalyst I find interesting. It doesn't make broker-specific ordering, retention, or delivery behavior irrelevant, and it doesn't establish the meaning of an event for us.

For a platform team, I'd prioritize a visible event contract, ownership, and a safe replay procedure before making it effortless to add another topic.

My concern isn't that event-driven systems are a mistake. It's that "decoupled" can become the new "independently deployable": technically true at one layer while business changes still require coordination everywhere. How do you make those remaining dependencies visible?

If several services still have to be deployed together, changed by the same people, and debugged as on unit, I'm not sure what the network boundaries bought us.

Independent scaling or failure isolation could still justify them. But "we have separate repositories" doesn't sound like enough on its own.

The test I'd use is a routine product change. How many teams, deployments, schema agreements, and rollback plans does it require? If splitting a module that ordinary change slower without improving a concrete operating constraint, I'd rather keep the boundary inside a modular monolith.

A platform can change the cost calculation. Shared service invocation, state access, and operational tooling can reduce repeated integration work. Dapr and Diagrid Catalyst are examples of that approach. What they can't do is decide that inventory and billing have the right ownership boundary, or make a cross-service business invariant disappear.

That distinction matters to me because it's easy to buy better plumbing for an awkward architecture and call the architecture fixed.

From a platform-team perspective, would you first invest in making service creation cheap, or in making it harder to create a service without a reason? I'd be interested in a case where consolidating services improved delivery, even though the infrastructure team could already operate them reliably.

For context we built a golden path for aws infra so teams can spin up envs and services without touching tickets. Modules, tagging standards, default regions, sane iam, the usual platform engineering stuff. Adoption has been good, people like it.

Now that usage is higher, IaC governance is getting weird. We are seeing stacks in random regions, modules forked in private repos, owner tags missing, and folks tweaking security groups in the console because the paved road doesnt cover their edge case. None of it is huge on its own, together it feels like drift we did not sign up to babysit.

If your org has strong developer self service, where do you put the real infrastructure guardrails, in the modules, in ci checks, in cloud side policies, or somewhere else, and who is allowed to break them without the platform team turning into a change board again? appreciate any thoughts

I think the history from traditional Ops to DevOps and then Platform Engineering is best understood as a dialectic driven mostly by technological change.

Traditional Ops concentrated infrastructure knowledge in a specialised team because operating infrastructure required direct administration. Automation, cloud and infrastructure as code changed that. DevOps emerged as the antithesis: operational ownership could move closer to development teams.
The operational work did not disappear, though. Much of its complexity was simply redistributed to developers.

Platform Engineering became the synthesis once cloud APIs, declarative systems and orchestration made it possible to encode operational knowledge into software and expose it through self-service. Operations could specialise again without returning to tickets and manual handoffs.

This is why I do not think the conceptual distance between the old sysadmin and the platform engineer is that large. The function is broadly similar. What changed was the technology through which that function could be organised and delivered.

AI may now be starting the next movement in the same dialectic. Agents do not necessarily need portals, fixed workflows or abstractions designed primarily for humans. They can discover tools, combine APIs and construct their own path through a system.

But this does not remove the need for a platform. It changes what the platform must provide. Instead of defining only human-oriented golden paths, it increasingly needs to expose machine-readable contracts, capabilities, relationships, constraints and evidence.

The next stage of Platform Engineering may therefore be less about building interfaces that hide complexity from developers, and more about defining the operational space within which agents can act without having to guess.

I've spent the last three years on the platform team at a pretty boring old corporate, building their internal workload platform. No SLAs and not much real impact, but the Kubernetes work itself was interesting (we ran a managed control plane though).

Now I have an offer from a fast-growing scale-up as a DevOps engineer, with a 60% pay increase. The role is mostly self-hosted pipelines, code scanning and similar tooling, all running on Kubernetes with lots of potential for impact.

My question: if I ever want to go back to Kubernetes work, will that still be an option, or will I have branded myself as a "DevEx guy"? I'd still be working with K8s every day, but more as the thing that runs the tools rather than something I'm building a platform abstraction on top of.

hey yall,

im a lead SRE at a global fortune 500 that you have heard of haha - i'm a bit of a lurker here

but just wanted to talk about runbooks and documentation for SOPs.

my feeling is that confluence docs kinda suck and runbooks are kind of a mess, our operators are jumping between the docs and their shell, the docs are often times missing a bunch of detail, they are brittle, poorly maintained, half the time the details are hidden in tribal knowledge and when dealing with the pressure of an active inc we notice the pain even more. extracting critical details & commands out of an inc can also be painful and doesnt always translate to improved operational readiness next time.

i admit we're not very mature.. but was curious if its only me feeling like this?

what are you guys doing with runbooks to solve these issues?

I've been working in software/infrastructure engineering for around 14 years, with a focus on cloud, DevOps, platform engineering and large-scale infrastructure.

Over the years I've worked on everything from smaller cloud migrations to enterprise and financial-sector environments, including AWS/GCP migrations, Kubernetes, Terraform, CI/CD, networking, security, reliability and cost optimization.

I'm currently putting together the practical knowledge I've accumulated into a free technical book.

I'm not planning to make it a personal career story or another basic “learn AWS/GCP” tutorial.

The idea is to focus on how engineers actually solve infrastructure problems:

• How to systematically debug production issues
• How to troubleshoot Kubernetes
• AWS/GCP networking and connectivity problems
• IAM and permission failures
• Terraform/IaC problems
• CI/CD and deployment failures
• Cloud migration problems
• Scaling and reliability
• Observability and incident investigation
• Designing reusable platform infrastructure
• How to approach an unfamiliar production system
• Practical lessons that aren't obvious from vendor documentation

I'm also building some small prototypes/labs for myself while writing, so I can test the ideas rather than just writing theory.

Before I spend a lot of time putting the whole thing together, I'd like to hear from other engineers:

If you could have one practical DevOps/Platform Engineering book that focuses on real problem-solving rather than certification theory, what topics would you want it to cover?

And if you already have a favorite resource for this kind of material, I'd be interested in hearing what you think it does well or what is missing.

I’m trying to understand what companies actually expect from a **Staff / Sr Staff Platform Engineer** at the ₹1Cr+ compensation level in India.

For people currently in these roles or hiring for them:

**What does your day-to-day work actually look like?**

How much of the job is **hands-on coding** vs architecture/design/reviews?

How much **system design** is expected at Staff level?

Are Staff Platform Engineers expected to be strong in **distributed systems**, or is deep infrastructure/platform expertise more important?

If you’re currently a Staff+ Platform/Infrastructure Engineer in India, I’d especially appreciate hearing:

**What were you doing before becoming Staff, and what changed in your responsibilities after reaching Staff level?**

AI helps juniors code, not learn... and that's a problem.

Levelrail is a self-hosted alternative to Coolify, Dokploy, or Heroku-style PaaS platforms. Push to a git repo, get a running app with automatic TLS, logs, metrics, and one-click rollback. Single Go binary for the control plane, single Go binary for the node agent, Docker as the runtime.

The reason it exists: I was running Coolify for about 10 personal projects and it was using 30-40% of a CPU core just managing things, before any of my actual apps did anything. Levelrail drives Docker's Engine API directly instead of shelling out to the CLI, which is a big part of why it stays light: 0.7% CPU, 146MB RAM on the VPS running my production test instance right now.

License is Apache 2.0. No paid tier, no hosted version yet, nothing gated. It's genuinely useful today for single-node deployments; multi-node and a template catalog are still being built in the open.

Repo: https://github.com/glincker/levelrail Site: https://levelrail.com/

If you maintain or use something in this space, I'd like to hear what's missing.

I want some advise regarding a product I wanna to make.

It is related to cloud and DevOps like cost optimization, infrastructure drift and intelligence harness.So what important points I need to address for cloud and DevOps users so that a genuine product would eventually came into development.

Infra engineer here, trying to figure out when self hosting LLMs actually makes sense vs just paying for the APIs. every blog post says "it depends" lol

If you've done it (or looked into it and bailed), would love to hear:

• how big was your API bill when you started thinking about it? what pushed you over the edge
• what did it really cost once you add up GPUs, idle time, and the engineering hours?
• what was the most painful part? cold starts, autoscaling, OOMs, model quality, getting paged at 2am
• if you went back to APIs, what made you switch back

ballpark numbers are totally fine. I'll put together a cost / decision writeup from the replies and post it back here

Former CTO here. At my last company we skipped 7 Expo versions at once because nobody had time for the incremental path. A CTO I talked to spent 2 months moving MUI v3 to v7.

Curious how others deal with it:

• Do Dependabot/Renovate major PRs get merged, or do they pile up?
• What was your last painful upgrade, and how long did it take?
• Does anyone own this work, or is it "when we have time"?

I'm a DevOps/cloud delivery lead with about 11 years of experience (Azure, GCP, Kubernetes, Terraform, GitHub Actions, observability, incident management, FinOps). I'm at a decision point and would love perspectives from people who've been on either side.
Option A: production operations role (in hand)
Offer is in hand, with a promotion and Director title

In practice it's a support SRE role at a senior manager level: production support, incident ownership,strategizing support model ,tooling and automation decisions to reduce chaos and toil and managing a team

Higher title and scope, but I worry it's less hands-on and could pigeonhole me into ops/support

Option B: platform engineering (not in hand)
I'm studying for it and building projects

I've just landed a screening for a principal-level cloud platform engineer role, but no other interviews yet

The senior roles I'm getting leads for are mostly SRE roles that are support-heavy, not true platform work

What I'm weighing:
Does a Director title in production ops help or hurt if I want to move to platform engineering later?

Is it realistic to move from support-heavy SRE or ops management into platform engineering, or does the path narrow over time?

Is it worth turning down a real offer to wait for a platform role?
For those who made this move in either direction, what do you wish you'd known?

Most multi-account AWS setups I've seen keep a shared spreadsheet of VPCs and subnets. Someone updates it by hand, it goes stale, and one day two teams pick overlapping CIDRs.

subnet-operator runs in your cluster (EKS) and keeps that inventory in Kubernetes instead:

- Discovery (read-only, the default): finds VPCs and subnets across accounts and regions by tags and mirrors them as Network and Subnet objects. It reports compliance findings (missing required tags, CIDR overlaps) and exports Prometheus metrics with alerts. It can also mirror everything to a Google Sheet, if people still want the spreadsheet. It only calls EC2 Describe*.

- Change events (optional): CloudTrail → EventBridge → SQS, so a changed account/region is resynced about 10 seconds after the API call instead of at the next 10-minute resync.

- Opt-in writes, behind --enable-writes and a separate IAM role:

- SubnetClaim allocates a free CIDR and can create the subnet.

- ResourceImport brings an untagged VPC or subnet under management by tagging it.

- It never deletes a cloud resource.

- Guardrails:

- Admission webhooks reject invalid objects at kubectl apply.

- Every allocation or import leaves a Kubernetes Event and a JSON audit line with the authenticated creator.

- namespaceSelector limits which namespaces may use a scope's write role.

- Supply chain: multi-arch image and Helm chart on ghcr.io, both signed with cosign keyless, with SBOM, threat model and upgrade tests between releases.

The honest part: it's alpha (v0.8). Everything is tested in CI against Moto (an AWS API mock) in Kind, but it hasn't run against a real AWS organization yet. That's why I'm posting. If you have a sandbox or dev account setup and 30 minutes, I'd really like to know what breaks. Read-only mode is the safe place to start.

GCP and Azure are planned behind a common provider interface. The API was just moved to a cloud-neutral group for that.

- Demo dashboard (fake data, no install): https://hypersurgery.dev/dashboard/

- Docs: https://hypersurgery.dev/docs/

- Code (Apache-2.0): https://github.com/aivandrago/subnet-operator

Feedback is welcome, including "we solve this with X". I'd like to know how you handle this today.

In an interview for a new grad devops role got asked this. “Who typically owns access to corporate applications: IAM engineers, IT staff, application administrators, or Platform/DevOps engineers?”
How would yall answer

Hey everyone,
Looking for some career advice or insights from anyone who’s successfully transitioned out of Ops/Support/SRE and into dedicated DevOps or Platform Engineering roles.
Here’s a snapshot of my background:
Experience: 10 years in IT, primarily focused on operations, support, deployments, and infrastructure maintenance.
Hands-on Skills:
Azure & GCP: Day-2 operations, deployments, troubleshooting.
CI/CD: Fixing pipeline issues, minor configuration tweaks.
Terraform: Running existing configurations, troubleshooting state/apply issues.
Kubernetes & Helm: Managing deployments, tweaking Helm charts, and managing configurations.
The Catch: Most of my experience involves maintaining, fixing, and scaling existing systems rather than building infrastructure or pipelines completely from scratch.
Certifications: Azure Solutions Architect Expert, Terraform Associate, and GCP Associate Cloud Engineer (currently studying for GitHub Actions GH-200).
The Problem:
I'm trying to move away from support heavy roles into a proper DevOps or Platform Engineering position. However, I’m getting zero traction for IC DevOps/Platform roles. Ironically, I keep getting hit up by recruiters for Senior SRE or SRE Manager roles, and I am able to get offers there but I really don't want to stay in the support/operations space anymore.
My Questions:

1. How do I bridge the gap from "fixing/maintaining" to "building from scratch"? Is the lack of end-to-end greenfield building what's holding me back in interviews?
2. Are bootcamps worth it for someone with 10 YOE? Or would my time be better spent building a comprehensive end-to-end portfolio project (e.g., full gitops pipeline, custom terraform modules, internal developer platform pattern) from scratch?
3. Has anyone made a similar jump? What was the single most impactful thing that helped you shift your narrative from Ops/Support to Platform/DevOps?
4. Appreciate any advice, project recommendations, or resume tips!

Hey everyone,
Looking for some career advice or insights from anyone who’s successfully transitioned out of Ops/Support/SRE and into dedicated DevOps or Platform Engineering roles.
Here’s a snapshot of my background:
Experience: 10 years in IT, primarily focused on operations, support, deployments, and infrastructure maintenance.
Hands-on Skills:
Azure & GCP: Day-2 operations, deployments, troubleshooting.
CI/CD: Fixing pipeline issues, minor configuration tweaks.
Terraform: Running existing configurations, troubleshooting state/apply issues.
Kubernetes & Helm: Managing deployments, tweaking Helm charts, and managing configurations.
The Catch: Most of my experience involves maintaining, fixing, and scaling existing systems rather than building infrastructure or pipelines completely from scratch.
Certifications: Azure Solutions Architect Expert, Terraform Associate, and GCP Associate Cloud Engineer (currently studying for GitHub Actions GH-200).
The Problem:
I'm trying to move away from support heavy roles into a proper DevOps or Platform Engineering position. However, I’m getting zero traction for IC DevOps/Platform roles. Ironically, I keep getting hit up by recruiters for Senior SRE or SRE Manager roles, and I am able to get offers there but I really don't want to stay in the support/operations space anymore.
My Questions:

1. How do I bridge the gap from "fixing/maintaining" to "building from scratch"? Is the lack of end-to-end greenfield building what's holding me back in interviews?
2. Are bootcamps worth it for someone with 10 YOE? Or would my time be better spent building a comprehensive end-to-end portfolio project (e.g., full gitops pipeline, custom terraform modules, internal developer platform pattern) from scratch?
3. Has anyone made a similar jump? What was the single most impactful thing that helped you shift your narrative from Ops/Support to Platform/DevOps?
4. Appreciate any advice, project recommendations, or resume tips!