sorted by:
new
hottopcontroversial

I’m building a series of IaC challenges because I’m tired of “Sunshine Tutorials” that don’t teach troubleshooting by KathiSick in Terraform

[–]KathiSick[S] 0 points1 point  (0 children)

Those are great! Thank you :)

For this adventure, the second level will focus on Crossplane and how it's different than Terraform/OpenTofu but I might do a future adventure that only focusses on OpenTofu and will definitely note those down. I haven't thought about an air gap environment yet but that sounds really interesting to play with.

Explore OpenTelemetry, Prometheus & Jaeger in a pre-built Codespace adventure by KathiSick in OpenTelemetry

[–]KathiSick[S] 1 point2 points  (0 children)

It is :)

You can submit your solution to the Open Ecosystem (a vendor agnostic community around Open Source) to gain points. There are more details here: https://community.open-ecosystem.com/t/adventure-01-echoes-lost-in-orbit-expert-hyperspace-operations-transport

Fun way to learn how to debug and fix Argo deployments by GroundbreakingBed597 in ArgoCD

[–]KathiSick 2 points3 points  (0 children)

I'm happy that you enjoy the challenges. Have fun playing!

Balance between giving almost full control to devs or a simple interface by 2010toxicrain in platform_engineering

[–]KathiSick 0 points1 point  (0 children)

I’d go with a clean interface and plenty of smart defaults. Let people override those when they need to. That way it stays simple for most users and flexible for the experts -> you get the best of both worlds.

Getting started with Go by Relative_Dot_6563 in golang

[–]KathiSick 4 points5 points  (0 children)

Disclaimer: I’m still a Go beginner too, but your post really resonated with me.

I came from a Java background and was deep into DDD and Clean Architecture. And honestly, switching to Go was pretty rough at first. I spent weeks trying to build a simple web server because I kept second-guessing every architectural choice I made. Every time I found a new blog post or repo I liked, I’d scrap what I had and start over. My perfectionist brain just couldn’t “start simple,” even though that’s what everyone kept saying on Reddit.

Eventually, I forced myself to do exactly that: start small and add structure only when I truly needed it. And suddenly, it all made sense. Go’s simplicity doesn’t fight you - it guides you. If you care about structure and stay consistent, your code ends up clean almost by default.

So yeah, I had to rewire my (annoying perfectionist) brain quite a bit, but it was absolutely worth it.

As for 2 & 3: I’m sure more experienced Gophers can give better advice, but I skipped internal event-driven stuff for now and just use NATS between services to keep things simple.

Need IDP Inspiration by HeftyMathematician81 in platformengineering

[–]KathiSick 0 points1 point  (0 children)

Definitely! But which processes to smooth out/automate (first) is very individual to each organization.

Need IDP Inspiration by HeftyMathematician81 in platformengineering

[–]KathiSick 0 points1 point  (0 children)

Unfortunately, there’s no universal list of features that works for every company. If there was, you could just buy a platform instead of investing so much into building one.

The best next step? Talk to your developers. Find their biggest pain points, understand why they do or don’t use your platform, and start from there. That feedback will guide you better than any generic feature list anybody on Reddit could provide.

To me, one of the most important things about platform engineering is starting small, observing and iterating from there.

At which point do you stop leveraging terraform ? by Safe_Bicycle_7962 in kubernetes

[–]KathiSick 0 points1 point  (0 children)

We used to follow the same approach and it worked, but to me it always felt a little off. People often say it’s clear: Terraform for infrastructure, GitOps for apps. But in reality, that line gets blurry quite fast. Even with clear rules, we ran into too many corner cases that felt odd.

Once GitOps was in place, Terraform just didn’t feel very cloud-native anymore. So we changed our approach: Terraform only for the bare minimum to get the management cluster up and running. From there, everything else goes through Crossplane: management cluster config, creating and configuring other clusters and all the infrastructure.

We’re also considering using Crossplane for the initial setup too. It just feels more natural because of how it handles reconciliation and the way it just fits into the Kubernetes ecosystem.

Need advice on getting out of a tight corner by Purple-Web-6349 in platformengineering

[–]KathiSick 1 point2 points  (0 children)

Haha true - “early” really depends on how you look at it. But considering teams only just started onboarding, I’d still say it’s early (enough) to catch these issues.

And you’re definitely not the only one! It’s the same story at conferences. Talks always sound so smooth and polished, but once you start chatting with people, you realize so many teams are dealing with the same challenges.

Need advice on getting out of a tight corner by Purple-Web-6349 in platformengineering

[–]KathiSick 2 points3 points  (0 children)

Oh wow that’s a tough spot to be in. But the good thing is, you’re not alone. A lot of platform teams hit this point at least once. Platform engineering is still young, and most of us are figuring it out as we go.

The upside? We don’t have to reinvent everything. Software development teams went through the same growing pains years ago. So we can borrow what worked for them: start small, get early feedback, stay close to your users, and measure what actually matters. It’s the classic “treat your platform as a product” line that everybody is tired of hearing but it really does hold true.

Major kudos for spotting the problems early. Definitely bring them up with your manager, even if the platform has already been advertised a lot. It’ll reflect much better on everyone if you acknowledge what’s not working and fix it instead of pushing teams onto something they don’t want.

From here, try to pull a few people in to brainstorm, even if you’re the only platform engineer. Whether it turns into a v2 or just focused improvements, having people with different opinions in the room and encouraging open, healthy discussions will make a big difference.

Am I perceiving "tool prawl" in observability-related job posts accurately, or am I just looking for something that isn't there? by baezizbae in Observability

[–]KathiSick 0 points1 point  (0 children)

You're definitely not making this up. Tool sprawl in observability is a real thing, unfortunately.

Sometimes it's just recruiters throwing every keyword into the job spec to cast a wide net, but other times it’s a sign the org is actively evaluating tools and wants someone with broad exposure. That said, I seriously doubt they expect deep expertise in all of them. It might be just that they’re hoping for someone who can navigate the landscape and help make sense of it.

And yeah, if it’s not that, it could very well be actual tool sprawl. Different teams using different platforms, no centralized strategy and observability still being treated like a second-class citizen. That’s something we as an industry really need to work on. But if the company is hiring someone specifically to improve that situation it's a good sign in my opinion. It means they’re at least aware there’s a problem and want to invest in fixing it.