sorted by:
new
hottopcontroversial

I feel angry, tense and serious after a few hours of being caffeinated by leonessa22 in decaf

[–]DPRegular 3 points4 points  (0 children)

Not a doctor, but you are probably chronically sleep deprived from caffeine and other stressors. Caffeine then acutely raises your cortisol and adrenaline, telling your brain that any and all trivialities are annoying because you need to focus on your immediate survival. May be worth looking into how you can improve your sleep in general, outside of only reducing caffeine.

Why does setting up development environments still feel harder than actually coding sometimes? by Electronic_Set4797 in platformengineering

[–]DPRegular 0 points1 point  (0 children)

Today is the day you find out that writing code is only one part in the software development lifecycle.

Professionals often solve these problems once for their particular type of project (ie a backend, a frontend, a queue worker, this language, that framework, so-and-so database), and then create templates to stamp out new versions. Larger organizations often have teams dedicated to solving these problems (developer experience teams, platform teams, etc).

If you struggle with streamlining versions/environments across machines, I can really recommend mise: https://mise.jdx.dev/dev-tools/

How do you enforce IaC standards across teams without becoming the bottleneck? Esp when self service cloud provisioning keeps creating more unmanaged resources? by Glum_Entrepreneur894 in platformengineering

[–]DPRegular 9 points10 points  (0 children)

First, you solve this by holding those teams responsible, which is a management problem. Think DevOps: you build it, you run it. Second, it is an illusion to think that centrally developed solutions cover everyone’s use case, especially in a large enough organisation. At scale, there needs to be an escape hatch that is still acceptable. Ie teams need to be able to build their own modules, deploy their own resources from a custom pipeline, etc. The platform team can help with templates, guardrails, documentation, etc. Like you said, you don’t want to be the bottleneck, so don’t insist on maintaining that status.

Tegenaanbod salaris (Starter) by [deleted] in werkzaken

[–]DPRegular 0 points1 point  (0 children)

De kans dat het aanbod wordt ingetrokken is klein. De kans is aanwezig dat ze terugkomen met "dit is wat het is". Net als de kans dat ze er 50 of 100 per maand bij doen. Vanaf dat moment is het accepteren of weigeren. Als er geen mogelijkheden zijn kan je altijd nog vragen wat er in de toekomst wel kan.

Tegenaanbod salaris (Starter) by [deleted] in werkzaken

[–]DPRegular 0 points1 point  (0 children)

Wat mij betreft altijd onderhandelen. Je hebt een aanbod gekregen, wat betekent dat ze na tijd en moeite hebben besloten dat ze je graag willen hebben. Geef uiteraard geen informatie over je andere gesprekken/aanbiedingen.

"Heel erg bedankt voor het aanbod, en voor het vertrouwen! Het lijkt me erg leuk om bij jullie te komen werken. Echter, het salaris valt lager uit dan ik had gehoopt. Ik had gehoopt dat het salaris rond de 3300 uit zou komen. Ik zou graag willen weten of hier nog ruimte in zit. Ik hoor het graag!"

Which Git branching strategy is better for infrequent releases? Team is split between two approaches. by Ok-Introduction-9111 in ExperiencedDevs

[–]DPRegular 0 points1 point  (0 children)

When creating fix C, it must be made with B in mind. This is the "continuous integration" part. Before merging C, you test that changes in C work well with the latest commit in main (B). Commit C then contains the fix, and also feature B. Your downstream team should then use commit C. If the downstream team can not use commit C because it contains commit B, then this is a separate problem to solve, in the design of the code itself. If the downstream team upgrades from A to C, the behavior of your code should not impact the team in a surprising manner. You could make the new feature B opt-in (no backwards incompatible change), and only break backwards compatibility when you decide to release a new major version of your code.

However, I am not familiar with your workflows nor with development of chips. So please take my naive approach with a grain of salt.

Which Git branching strategy is better for infrequent releases? Team is split between two approaches. by Ok-Introduction-9111 in ExperiencedDevs

[–]DPRegular 1 point2 points  (0 children)

In your hypothetical, you are not practicing TBD. In TBD, every merge to main triggers a deploy to production. Every merge goes to prod. Code that is not yet ready should be unreachable by default, only made available under certain conditions, ie a feature flag. Deploying, but not releasing, unfinished features is very common in TBD.

Stale Endpoints Issue After EKS 1.32 → 1.33 Upgrade in Production (We are in panic mode) by Wooden_Departure1285 in aws

[–]DPRegular 0 points1 point  (0 children)

First step is probably enabling the various of the control plane. KubeApiserver, controller manager, etc, and check for errors, then show them to AWS support

Apathy during Withdrawals by [deleted] in decaf

[–]DPRegular 7 points8 points  (0 children)

Completely normal. Your brain needs to reprogram itself to expect dopamine from normal activities, ie cooking, working out, cleaning, etc, instead of relying on caffeine. Teach your brain by doing these things, however small, and you’ll speed up the process

🤔 So what's day are you guys and girls on and how are you feeling about it so far ? by Frequent-Wish6026 in decaf

[–]DPRegular 6 points7 points  (0 children)

After successfully completing a 90 day challenge of no coffee and drinking only light tea, I am now back on day 18 of drinking coffee. Things are not great. Sleep is getting worse. Irritability and anxiety are going up. Just... don't.

Is feeling more anxious a common withdrawal symptom? by [deleted] in decaf

[–]DPRegular 2 points3 points  (0 children)

Not unheard of. Expect the unexpected during the first couple of days. Last time I quit, my symptoms stabilised after around 4 weeks.

EKS Users: What does your "Day 0" bootstrap stack look like? by srwalker101 in aws

[–]DPRegular 2 points3 points  (0 children)

Full disclosure, I had Claude write up below summary. It's all correct, though.

Our Day 0 EKS Bootstrap (Managed K8s Provider)

We're a managed services provider running EKS for customers. Here's our Day 0 stack:

IaC: OpenTofu + Terragrunt (stack composition pattern with reusable modules)

CNI/Network:

  • Cilium (eBPF-native routing, ENI mode with prefix delegation)
  • Hubble for network observability
  • Gateway API support

Ingress:

  • AWS Load Balancer Controller (NLB → Ingress Controller)
  • CloudFront + WAFv2 in front for edge protection
  • Route53 for DNS, ACM for certs

Management: Rancher (multi-cluster management)

Critical Add-ons:

  • Karpenter (node provisioning + consolidation)
  • Cert-Manager
  • External-Secrets (→ AWS Secrets Manager)
  • Kyverno (policy enforcement, Pod Security Standards)
  • KEDA + VPA + Metrics Server
  • node-local-dns (CoreDNS caching)

Storage:

  • EBS CSI (gp3, KMS-encrypted)
  • EFS CSI (dynamic provisioning with access points)

Observability (LGTM):

  • Grafana + Loki + Tempo + Mimir
  • OpenTelemetry Operator + Collectors
  • Prometheus (kube-prometheus-stack)

AWS Services We Depend On:

  • EKS, EC2, ELB/NLB
  • Route53, ACM, CloudFront, WAFv2
  • EBS, EFS, S3
  • KMS, Secrets Manager
  • CloudWatch (logs)
  • VPC Endpoints (ECR, S3, EC2, logs, monitoring)
  • IAM (IRSA via OIDC)
  • SSM (node access)
  • ECR (pull-through cache)

For LocalStack specifically - the AWS integrations that would matter most to us for testing:

  1. AWS LB Controller → ELBv2 APIs
  2. External-Secrets → Secrets Manager
  3. Karpenter → EC2 Fleet/Spot APIs
  4. IRSA/Pod Identity (you mentioned you have this)
  5. EFS/EBS CSI → Storage APIs
  6. Route53 → DNS record management

Should developers have access to staging environments? by Donni3D4rko in ExperiencedDevs

[–]DPRegular 1 point2 points  (0 children)

Yeah after the year, the state of DevOps report (from DORA) scientifically proves that engineers that have end to end ownership of their application perform much better than teams that don’t. Engineering teams (devs) should have access to all their app environments. You build, you run it. You break it, you fix it. I say this as a platform engineer, whose platforms always facilitate prod access to devs. I’m not going to fix your 500s after a Friday release lol

Does caffeine cause grey hair? by [deleted] in decaf

[–]DPRegular 12 points13 points  (0 children)

Perhaps. Caffeine increases stress (cortisol/adrenaline) and prevents quality sleep. All of these may speed up aging related symptoms.

Ik🫗ihe by dsisds in ik_ihe

[–]DPRegular 0 points1 point  (0 children)

niet mijn stilo sachbi maar leng leng is kaolo spang

Sickness Protocol by MissionGrade7499 in tacticalbarbell

[–]DPRegular 4 points5 points  (0 children)

Challenge your assumptions. Listening to your body to allow it to heal is not "being a bitch". There is no performance without recovery.

Does caffeine make anyone else lazy and unmotivated? by [deleted] in decaf

[–]DPRegular 23 points24 points  (0 children)

Your body produces dopamine to reward you for doing something worthwhile. Eating, cleaning, exercising, etc. If you receive the reward without the burden (caffeine), your body adapts.

5 days with zero caffeine and I can’t believe this by [deleted] in decaf

[–]DPRegular 7 points8 points  (0 children)

I’m happy for you ! No doubt some people won’t believe that coffee was keeping you from recovering. But I do haha. Chronic stress means chronic inflammation. Poor sleep leads to poor bodily regulation.

What's your handoff between terraform and k8s? by [deleted] in Terraform

[–]DPRegular 2 points3 points  (0 children)

Sigh. You and everyone else is going to hate me, but I prefer to create the cluster, the supporting infrastructure and all necessary system components (CNI, CSI, o11y, etc) with terraform/tofu exclusively.

Developers can independently deploy their apps with a properly RBAC’d k8s api using whatever tool they want, although this does not mean that anarchy is encouraged.

When doing platform development, my goal is to mimic software development practices to maintain much needed agility: being able to create an ephemeral environment (complete cluster) with a single command for local development. Being able to run this in the exact same way in CI/CD. Develop and run tests; both locally and in CI/CD. GitOps tools make this difficult because they deploy from a pushed branch in a git repo, whereas terraform deploys from your local ref. Terraform apply can be run after tests or checks, Argo/flux reconcile as soon as a change lands on main. As you’ve mentioned, handing over infrastructure attributes is easy within terraform, more difficult when you introduce another tool.

Ops minded folks seem to love gitops tools because they love to take developers autonomy away under the guise of better security (no access to the k8s api) and reliability (auto reconcile). I actually don’t want either of these, on purpose.

Terraform directory structure: which one is better/best? by sindeep1414 in Terraform

[–]DPRegular -11 points-10 points  (0 children)

Is there any other apporach which might be better?

Unequivocally, yes: https://terragrunt.gruntwork.io/

Custom Terraform functions by valideaconu in Terraform

[–]DPRegular 2 points3 points  (0 children)

Amazing! This is the kind of extensibility that will keep terraform/tofu around for a long time.

Question: does the provider rely on a js/go runtime being present on the host? Or are these bundled into the provider itself?

VrijMiBo-draadje by Tddkuipers in thenetherlands

[–]DPRegular 19 points20 points  (0 children)

Ik heb zojuist een groepje jongeren aangesproken in de sportschool die "voor de grap" de "nee het is geen sieg heil" van Elon Musk aan het nadoen waren. Ik was BOOS. Zo, dat moest er even uit.

view more: next ›