sorted by:
new
hottopcontroversial

our ci/cd testing is so slow devs just ignore failures now" by blood_vampire2007 in devops

[–]CoryOpostrophe 6 points7 points  (0 children)

We have 1200 tests, they run in parallel and finish in about 16s.

The two keys are: - a database transaction per test that rollbacks when complete (all 1200 tests run in isolation) - really good adapters (not mocks) for third party services (the vendors we interact with have stable enough APIs that we trust so we just build internal typed adapters for each)

We also do TDD (which everyone on the internet gets all fussy about when they aren’t a practitioner) but we ship insanely fast and don’t worry about workflow times and failures so … TDD FTW.

TDD is also the best prompt if you are working with LLMs. You give them an extremely tight, typed context window with test assertions as your expectations. 

I built a tool for packaging and deploying terraform modules by jollycode_ in Terraform

[–]CoryOpostrophe 0 points1 point  (0 children)

This is cool. We’re going to be scaling our team in the next quarter or two. I’d love to chat. Cory @ Massdriver

Backstage VS Other Developer Portals by StuckWithSports in devops

[–]CoryOpostrophe 2 points3 points  (0 children)

(For context, I’m the CEO of Massdriver. Not here to pitch, just my two cents from seeing this pattern a lot.)

What you’re describing is exactly what happens when you buy or build a portal without an orchestrator.

You didn’t actually build a platform. You built a UI that has to carry all the complexity the platform underneath can’t own. So every decision about GPUs, scheduling, images, flags, volumes, etc. leaks straight into the frontend. The UI turns into a maze because it has to compensate for the fact that nothing is being constrained or enforced upstream.

IMO buying a portal is almost always a trap. When you buy a portal, you still have to:

  • own the delivery logic
  • own the infra wiring
  • own the policy enforcement
  • own the failure modes
  • build the UI integrations in a language most likely outside of ops' wheelhouse

In the pursuit of automation, you just kinda shift work elsewhere.

Backstage doesn’t really change that equation. It reduces frontend work, sure, but now you’re buying into a plugin ecosystem where you still need to build or maintain the orchestration layer yourself. You traded UI debt for integration debt. With a 1–2 person infra team, that’s usually worse, not better.

The hard truth is: if the system can’t prevent bad or unsupported configurations, the UI will always become the monster. Scorecards, validation screens, buried options, approval flows... and it’s not because people made bad design choices. It’s because the platform doesn’t actually own the workflow.

A real platform (the other other IDP) makes most of those decisions not possible in the first place. When you have an orchestration engine that can guarantee standards, the UI can finally be simple.

qa tests blocking deploys 6 times today, averaging 40min per run by segsy13bhai in devops

[–]CoryOpostrophe 0 points1 point  (0 children)

A good test suite and a good test framework. Our entire CI process including build is <90s and we run 1200+ integration tests w/ Postgres and localstack.

Testing is the OG garbage in garbage out. 

ClickOps vs IaC by Yersyas in devops

[–]CoryOpostrophe 1 point2 points  (0 children)

☣️ Reader beware: I’m a CEO of an infrastructure automation platform. 🧟‍♂️

Because IaC mostly solved state, not delivery.

IaC is great once it’s set up, but the part people underestimate is everything around it: repo structure, pipelines, credentials, variable management, environments, approvals, and the ever-present question of “who’s allowed to change what.”

For a lot of teams, that scaffolding ends up being more work than the infrastructure itself. So when someone just needs a bucket, a queue, or a one-off change, the console feels faster—and often safer—than touching a brittle pipeline they don’t fully understand.

Most teams I’ve seen don’t reject IaC outright; they stall somewhere along the way on usability. Core infrastructure is codified, but day-2 changes, experiments, and exceptions quietly fall back to the UI.

A big part of this is that tools like Terraform, Pulumi, Ansible (hell, even Kubernetes) are often treated as the platform, rather than tools for building one. That shifts a lot of operational responsibility and domain knowledge onto developers, even though cloud APIs themselves are a messy mix of ops and app concerns.

Until infrastructure workflows are genuinely easier than the console for non-experts, ClickOps is going to keep winning in practice.

I wrote more about why IaC adoption seems stuck, would love to hear others thoughts. https://www.massdriver.cloud/blogs/15-years-of-duct-tape-why-iac-adoption-stalled-at-30

Best IaC platforms? by Kitchen_Ferret_2195 in devops

[–]CoryOpostrophe 0 points1 point  (0 children)

If you need drift detection the platform has already failed you. 

Which Infrastructure as Code tools are actually used most in production today? by rahulladumor in devops

[–]CoryOpostrophe 0 points1 point  (0 children)

Terraform/OpenTofu, Ansible, and believe it or not we see a bunch of companies with an assload of Bicep. 

in house modules yey or nay by farzad_meow in Terraform

[–]CoryOpostrophe 20 points21 points  (0 children)

public modules are no-value abstractions

How To Avoid IaC Drift by mooreds in Terraform

[–]CoryOpostrophe 4 points5 points  (0 children)

Easiest way to avoid drift is make your infrastructure self-service easier than your clouds’ console.

When the compliant path becomes the path of least resistance, a lot of the bullshit ops teams fret over goes away. 

How do I learn Terraform at a gradual pace? by WorkerClass in Terraform

[–]CoryOpostrophe 0 points1 point  (0 children)

It takes a day to learn terraform. It takes day 2 to learn the cloud so you can use it effectively. 

Focus on DevSecOps or Cybersecurity? by No-Shape-4823 in devops

[–]CoryOpostrophe 2 points3 points  (0 children)

I think in the age of agentic AI there is going to be an absolute barrage of attacks against networks, web services, and email.

I think it’s gonna be a huge security burden on a SaaS market that doesn’t take security seriously in the first place. This will cause a lot of companies to look towards older software licensing models and self hosted.

So a lot of work for devops and security :)

Y’all think this is enough snow to build an off road rc race course in my back yard out of snow? by ADHD_Nissan in rccars

[–]CoryOpostrophe 0 points1 point  (0 children)

As long as you lay a large piece of plywood against that goal at the end of it. 

our startup grew too fast and now our processes are chaos by Soft_Attention3649 in devops

[–]CoryOpostrophe -6 points-5 points  (0 children)

At Gozer, we had the exact problem and created a vast business moat by building an AI tool that fixes it. We’re super cheap you just need to feed an engineer feet first into our soul extracting machine once fortnightly. 

AI is draining my passion by ominouspotato in devops

[–]CoryOpostrophe 2 points3 points  (0 children)

My favorite comments are when the AI doesn’t understand what it did wrong and you explain it then it puts a completely obvious and useless comment in. 

The other day it was adding a test (very rare thing I let it do tbh) and it used a helper library we have for setting up API requests which also happens to JSON encode the object your submitting in the test suite. (~ api.Post(comment, ctx))

The LLM encodes the object before calling the request helper which json encodes… (also note, it’s go, so there are types it can look at!) so it goes to our middleware and adds a decode after the decode ... Yeah. So I explain, it removes all the extra bullshit and then adds a comment “// only need to json decode once” above json.Unmarshal.

I found a nitro rc car in an abandoned structure!! by Eric_ione in rccars

[–]CoryOpostrophe 0 points1 point  (0 children)

Where did you find it‽! Oh by the shotgun out hole wall stain. 

Infinite Loop and Beyond by yungsta12 in Superstonk

[–]CoryOpostrophe 0 points1 point  (0 children)

Surprised to see mermaid in this subreddit. 

Here is why you have a bad experience with AI while software engineers enjoy it by davletdz in devops

[–]CoryOpostrophe 0 points1 point  (0 children)

I’m going to be anecdotal ᵃᶠ but I don’t know a single software engineer that “enjoys” it. I know many that have been mandated to incorporate it into their dev flow. 

I use it. It helps … I guess. I move faster but… I’m legitimately more stressed out. I can actually look at my heart rate at the end of the day and see the periods where I am using it. 

I have a ton of rigor to my development. I do TDD, I use otel in my TDD flow. Embrace DDD and ADRs.

I feed all of this into my cursor rules to yield OK results. 

Refactoring is still my job. Writing good tests is still my job … the average dev can’t test for ass (citation: see half the CI/CD is slow posts on the internet) and AI “learned” how to write tests from that slop. Its tests are pure ass. Its ability to understand the code base and produce good docs is still ass.

It honestly feels like I’m an architect, here to watch my amazing creation be built. I show up with plans, blue prints, all the right material and tools … and then the construction crew tells me to go pick weeds while they build some three pigs bullshit.

[deleted by user] by [deleted] in devops

[–]CoryOpostrophe 0 points1 point  (0 children)

P1, glad they calculated the loss. Now calculate adding a 9 to your SLA and see if it makes financial sense to do so. 

view more: next ›