I've been in cloud / IT space for about 15ish years now, and at some point in the last few years I became quite jaded with all the new shiny tech things. I had a lot of trouble buying into the K8s ecosystem when I could do magical wonderous things with SSH and Ansible, and most conversations with my colleagues at the time were unconvincing at best - they would say K8s can do blah blah, and I would point to our Ansible playbooks that were already doing the same thing. The problem for me was less about the differences in technology but more about finding the willingness to learn something just because I have to.
I've since learned to recontextualize these things in terms of people. CI/CD isn't good because it's better than SSH, it's good because people who speak English can understand a simple devops pipeline but not my custom SSH wizardry. It's a way of inviting developers and even non-tech mgmt folks into my arcane world of development / production and allowing them to see what's going on under the hood. My incentive now isn't about what CI/CD tech is better or worse, rather does it allow my team / peers to understand what I'm trying to achieve and join in. And ultimately that's what I get paid to do - I don't get paid to do cool tech stuff, I get paid to make other people's work easier, or at least that's how I see devops / CI/CD. I know I can always find easier ways to do things, but will they necessarily understand them?
Very well said.
These tools help businesses move forward without having to involve a programmer for every little change.
Also there are quite a few analytically strong and talented folks out there, who do not know programming. Given the right set of tools, they can make quite an impact.
Definitely true. I’ve also seen even the most technical people benefit greatly from the artifacts produced by CI tools.
When each commit (or each RC etc) has automated regression testing for output quality, performance, or XYZ metric critical for your business, the artifacts/reports from those code changes can be stored and audited when unexpected things happen during a release crunch.
We’ve had teams that shrugged off integrating with our CI tools, then a ”final” manual quality check on their release builds’ output showed significant regressions in completeness/accuracy. They scramble all their troops to run through the merged commits to find the culprit(s), and jeopardize delivery.
A basic CI setup could have posted perf/recall/whatever stats to their PR thread for each merged change, or better yet block the merge at some threshold for regressed metrics.
I definitely had the same view initially of CI, similar to unit test suites or verbose structured logging… things I viewed as complete overkill. What I learned was that these things DO still feel like overkill until the moment you really need the ability to reliably audit how each change affects an evolving large system
> These tools help businesses move forward without having to involve a programmer for every little change.
Guess what — they will hire a programmer to do it anyway. They just can't be arsed as long as there is a warm body to boss around that will do it for them. It also strokes their egos, so why roll up the sleeves?
Same pipe dream as low code/no code tools enabling executives to create workflows on their own, which never happens in real life — it's "I had Kevin do it for me" all the time, every time, where "Kevin" is usually a programmer.
Same pipe dream as imagining everyone contributing to the in-house tools they are using and "collaborating". It just never happens. Everyone is happy to dump their feature request onto Andy who developed them in the first place and whine if the Andy is taking too long to implement them.
No amount of added eye candy and wishful thinking is going to change this. Even discovering Santa mating with Nessie is more likely.
You realize how much UX is important in CICD at the same time you realize everything outside of product/IT (and half inside IT) isn't version controlled, change managed, and/or automatically deployed.
More user friendly dev tools are the way to get people to do these things.
For more on these themes, check out Seeing Like a State by James C Scott. What he says about legibility, and especially
how the administrative state necessarily ignores any information which couldn't be made legible to them, helped me understand better how to convey realities to managers working outside the trenches.
It's funny that you say that because no management and barely any devs actually understand k8s, they understand its a resume bullet point and it sounds like the thing so they go for it.
They don't need to care about k8s. They just need to care about the text file I sent them which has HA/DR rules and other things customers might care about which requires their input / signoff. As a trivial example, as long as they understand that "replicas:1" is bad or that increasing the number means we get more processing power, I can reliably talk to them about important customer-impacting things. It's definitely hard to make your entire infrastructure commmunication-friendly but, back to OP's point, some tools let you do this better than others.
I've since learned to recontextualize these things in terms of people. CI/CD isn't good because it's better than SSH, it's good because people who speak English can understand a simple devops pipeline but not my custom SSH wizardry. It's a way of inviting developers and even non-tech mgmt folks into my arcane world of development / production and allowing them to see what's going on under the hood. My incentive now isn't about what CI/CD tech is better or worse, rather does it allow my team / peers to understand what I'm trying to achieve and join in. And ultimately that's what I get paid to do - I don't get paid to do cool tech stuff, I get paid to make other people's work easier, or at least that's how I see devops / CI/CD. I know I can always find easier ways to do things, but will they necessarily understand them?
Just my 2 cents. Hope this helps.