4 ms·
As a cloud/DevOps consultant, I don't believe in letting management drag on the life support of failed deployments. We (the team I built out since a couple yea
by devops99 2y ago
As a cloud/DevOps consultant, I don't believe in letting management drag on the life support of failed deployments.
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.
- remram 2y agoIt's really hard to parse what you are trying to say in the middle of this colorful imagery and quotations, but if you are spinning up a new Kubernetes cluster (and AWS/GCP account) per deployment, it's obvious you don't need this tool.
- devops99 2y agoSpecifically, leaving the corporate political dynamics aside, we move the workloads to the deployments that are up to standard and then archive+drop the old ones. Very simple.
- remram 2y agoA more cynical man than I would say that if you need to recreate all your workloads on a new cluster to bring them up to standard, "you seriously fucked up as DevOps / cloud admin / whatever"
- devops99 2y agoHeh, they aren't ""our"" workloads, before we get there, and not until they get deployed correctly for the first time ever at which point then and only then are they ""our"" workloads.