12 karma · joined November 27, 2024
This thread is about K8s Pods (and other K8s resources) that have been sitting idle, not memory leaks in software.
As far as "spilling" memory, the problem has already been solved by Rust which does not do garbage collection because it has static memory mapping. Does this mean egregious amounts of memory won't be used by some Rust programs? No. But unlike languages with garbage collection, where Rust is using that memory it is actually doing something with that memory.
This makes sense for K8s resources that ARE still serving production traffic. But this overall thread is about a tool to remove applications ARE NOT serving production traffic.
> Migrations at large companies can take multiple years
Depends who is in charge and who management considers worth listening to (some of us don't struggle so hard in this area).
> I can install this tool with helm in approximately half a day.
A script I wrote to find unused resources took less than 10 minutes to write.
Instead of Compton a short ride from Beverly Hills it's like the houses from those two wildly different hoods all stacked in a repeatedly alternating sequence.
Some tell me that Ansible is supposed to be better, I still prefer doing these things in Salt, in the yet rarer and rarer occasion something is not being run in some form or another of "distroless" container.
Just outsource.
Outsource to those who do have DevOps people who know what they're doing -- most companies do this already in one form or another.
I am very convinced it does not. I think where the apex between our viewpoints lies is what we recognize (or not) as "best" teams.
Two of our clients are large (15,000+ employees, and 22,000+ employees) orgs. Their tech execs are happy with our work, specifically our software delivery pipeline with guard rails and where we emphasize a "Heroku-like experience".
One of their projects needed HiTRUST, and we made it happen for them in under four weeks (no we're not geniuses, we stole the smarts of the AWS DoD-compliant architecture & deployment patterns) and the tone of the execs seemed to change pretty significantly after that.
One of these clients laid off more than half their IT staff suddenly this year.
When I was in individual contributor role in a mid-size (just under 3,000 employees), I wrote my thoughts, "internal whitepaper" or whatever being fully candid about the absurd struggles we were having (why does instantiating a VM take over three weeks?), and sent it to the CTO (and also the CEO, but the CTO didn't know about that) and some things changed pretty quickly.
But yeah, things suck in large orgs, that's why large orgs are outsourcing which is in the most-downstream customers' (the American peoples') best interests too -- a win-win-win all around.
So a K8s namespace named test02, another named test-featurebranch, and another named staging-featurebranch, all have their own Git branch with whatever Helm, OpenTOFU, etc.
With this pattern, and other patterns, we have a principle "if it's in the Git branch, we intend for it to there, if it's not in the Git branch it can't be there".
We use Helm to apply and remove things -- and we loved version 3 when it came out -- so there's not really any way for anything to linger.
We (the team I built out since a couple years ago) carve out a new AWS subaccount / GCP Project or bare-metal K8s or whatever the environment is, instantiate our GitOps pipeline, and services get cut-over in order to get supported.
When I was working in individual contributor roles, I managed to "manage upward" enough that I could establish boundaries on what could be supported or not. Yes this did involve a lot of "soft skills" (something I'm capable of doing even though my posts on this board are rather curt).
"Every DevOps job is a political job" rings true.
Do not support incumbent K8s clusters, as a famous -- more like infamous -- radio host used to say on 97.1 FM in the 90s: dump that bitch.
So, as a DevOps practitioner myself, I had enough say within the organizations I worked at, who are now clients, and also my other clients, that anything not in a dev environment goes through our GitOps pipeline. Other than the GitOps pipeline, there is zero write access to anything not dev.
If we stop using a resource, we remove a line or two (usually just one) in a manifest file, the GitOps pipeline takes care of the rest.
Not a single thing is unaccounted for, even if indirectly.
That said, the DevOps-in-name-only clowns far outnumber actual DevOps people, and there is no doubt a large market for your product.
edited: added clarity
Damn, that's fucking crazy, and also really depressing at the same time.
https://xcancel.com/realGeorgeHotz/status/1868356459542770087 brew install cyphernetes
at the top of the page is an immediate turn-off. https://xcancel.com/TechEmails/status/1868368310024462791But yeah, you sound vaccinated.
It's in there, among all the other shouting.
Alex and the circa 2010 Occupy Wall Street crowd have a lot more in common with each other than the "other side", which would be the warmongering "Neocons". But this might be more than some will want to contend with cognitively. Easier to bamboozle someone than tell them they have been bamboozled, and all that.