#random (2024-08)

is it different than other technical debt? https://apenwarr.ca/log/20130407

personally I think for infrastructure as code you have an additional technical debt vector which is the organization and maintainability of the code itself in addition to architectural short-cuts one takes to move quickly

or DevOps process debts

Ya I can agree with that ^. Tech debt seems like debt incurred due to stop-gaps (or short-term fixes) that eventually needs to be paid off (either by incident+work or by tickets+work)

i prefer Avery’s definition. people think wrongly about tech debt. you take the debt (mostly willingly) because it is the right thing to do now, to prioritize outcomes and learn about use cases. you pay it down when doing so is the right thing to do.

i agree with that too. the right thing to do is another way of saying using a practical stop-gap that incurs debt which is OK

but the debt always needs to be paid somehow lol

sometimes by declaring bankruptcy! and sometimes that’s ok!

Not sure if this answers your question but I will vent just the same!

I dislike the debt caused by tool/software updates that affect stable code. For example, new features and deprecation of old features may warrant an update to a codebase that works perfectly.

So the decision can be keep using the version of the software and libraries/providers that work when the code was deployed….

or update the code to match new software requirements.

I’m firmly in the camp to update code, I just groan loudly when i have to update perfectly good code.

@loren I think a lot of what people called technical debt is not so deliberate, though. A lot of it, I would argue, is people making decisions without putting a lot of thought into it

I think my technical debt is made up of 2 parts

1. stupid decisions because I was not aware of the full implications of using a specific technology, or the requirements changed down the line that made a previously smart decision stupid <- this is rotten technical debt but sometimes inevitable because I have a limited cognitive capacity, and cannot reliably see into the future
2. shortcuts I consciously take to launch quickly and experiment <- this is useful technical debt, and prevents over engineering I was watching a youtube video (but cannot remember the title) about software engineering not being a craft, and that treating it as a craft leads to a lot of over engineering in search for a global maxima that doesn’t serve the business, and sometimes the best code is the good enough code

I don’t know if I whole heartedly agree with this, I enjoy building things (I have a 100 pet projects that no one ever used), but in the context of business and trying to create value this is an important perspective

Re: software engineering as a craft. my favorite way to look at it is software is a substrate for producing something, like, for example, clay. If you’re an artist, clay is how you express your creativity. If you’re an engineer, clay is a tool in your bag to build a house or a roof, if you’re a kid, it’s something fun to play with and throw around. So, you can do engineering with software, and you can do art with it. It’ll look like text in a file in the end, but how it got there is different.

I tend to look at it more like engineering, and just like building a house or a bridge, you have to work with what’s available to you on budget and on time.

@Igor Rodionov @Jeremy G (Cloud Posse)

@Erik Osterman (Cloud Posse) ^

I watched the demo video. I think it would be a bit odd for a real world company to deploy their infrastructure like this today when Infrastructure as Code is pretty much the modern standard ?

My hope is to provide developers with an alternative to infra as code, just the same way text-to-code helps developers with normal coding tasks. Not super focused on large companies at the moment.

Chainguard, the only one I know

https://www.chainguard.dev/

I even personally witnessed syntactically incorrect TF code generated by chatGPT. It was not so long ago with 4o version I believe.

You have to do few shot prompting for things like standardized code. Or a pre-prompted agent with example resources.

It’s off sometimes, I just double check the docs after I’m done

1password, using their new service accounts

SSM but have also used Doppler before and had a positive experience

SSM. More importantly, what does your access pattern look like? One of my all time favorites is shipping chamber with my application and starting it inside chamber, so that my application remains decoupled from any particular secret-store and just reads environment variables

That type of env-var-only setup can be replicated on almost any provider, but it’s so painful to see devs writing code to fetch secrets

ssm/chamber is still great, I want to try 1password at some point tho too. Can be used easily outside of aws but we still have gcp devs sometimes writing new secret handling from scratch just cause they look up ssm and it’s in aws . Another downside is it’s also painfully slow to manage >50 params via terraform in my experience, with also checking the dependencies that fill those params

We’re not using chamber, but we are setting environment variables based on SSM params. Agree that I don’t want devs fetching secrets themselves.

For those passing secrets into AWS resources (e.g., ECS containers) from 3rd party providers like 1Password, what does your pipeline look like?

• Is it Terraform to glue the two providers together?

• Do you use environment variables to pass secrets explicitly?

• Something else altogether?

@Rishav Yes, we have a script there loads the secrets from 1password into terraform and then deploy. Works same way locally and in GitHub pipelines.

Oh neat, and how does the script authenticate access to 1Password?

And by loading into Terraform, is that via variables input or injection via TF_VAR_<name> environment variables?

I store my SOPS-encrypted secrets in git, and deploy them as Kubernetes Secrets. I aspire to move to https://openbao.org/ (the FOSS version of Hashicorp Vault) when I have more free time. Alternately, I’m curious about Bitwarden’s new secrets manager product: https://bitwarden.com/products/secrets-manager/

Yo, tech nerds and DevOps junkies! We just dropped a fire episode of “Packaging Pioneers: Docker, Inc and NixOS Friendly Feud” and it’s packed with mind-blowing stuff! And guess what? This is just the first of infinity episodes where Docker and Nix are gonna sit down and chat!

Ever thought about what’d happen if Docker and Nix had a tech face-off? Well, we made it happen, and boy, was it wild! In this geeky showdown, our container champs spill the tea on:

• How to wrangle dependencies like a boss (it’s like herding cats, but with more YAML)

• Docker’s secret sauce for making deployments smoother than a baby’s bottom

• Nix’s crazy obsession with making stuff repeatable (not just for lab coats anymore!)

• Config management tricks that’ll make DevOps engineers lose their minds

Heads up: This episode’s got more tech lingo and container puns than you can shake a stick at. Listen at your own risk!

Ready to dive into this nerdy goodness? Catch us on:

Spotify Castbox SoundCloud Apple Podcasts Amazon Music YouTube Podcasts Deezer Podbean Podcast Addict Transistor.fm

All these are just a click away at: https://lnkd.in/dQ_jisKT

Tune in now wherever you get your podcast fix or at visionaryx.tech. Don’t forget to smash that like button, leave a review, and tell your tech buddies!

P.S. If this episode doesn’t level up your container game, we’ll eat our Dockerfiles for breakfast!

hashtag

#Docker hashtag #Nix hashtag #NixOS hashtag #DevOps hashtag #Containers hashtag #Podcast hashtag #TechTalk