4 ms·
My complaint comes from the at scale part. I don't do anything at scale. I don't have to scale. My core competency is as a library or tool builder, and often m
by timeinput 6y ago
My complaint comes from the at scale part.
I don't do anything at scale. I don't have to scale. My core competency is as a library or tool builder, and often my primary deliverable is a tool or library.
In the past year I got a new JR engineer on my team who was all hot and bothered with docker and k8s and he spent a month changing out CI process to be docker based. It went from a 20 line shell script to a pile of garbage.
I disagreed with the decision at the time, and while a subject matter expert I'm not the team lead so I couldn't say no stop that's bad.
While I'm sure k8s solves problems for Google I'm not google. My company isn't google, and my team isn't solving that class of problems so docker is useless crap for me.
The person is no longer on the team. They left their docker mark, and ran off to dockerify some other project leaving a team with no container expertise and a CI pipeline that is hacks around docker bugs.
- bacongobbler 6y agoSounds more like a people problem than a tech problem.
- xorcist 6y agoEverything is a people problem at the end of the day.
- Karunamon 6y agoThis is a thought-terminating cliché. The existence of right tools for the job implies the existence of wrong tools for the job. The engineer in GP's story used the wrong tool for the job. That is a people problem. Had he used the right tool for the job, the problem would not have existed. GP wrote their CI stuff in shell to solve a tech problem, not a people problem.
- lnenad 6y agoDocker on its own is in most cases a great thing with a plethora of benefits. It's worth the upgrade from a 20 line shell script and I feel like you're part of the "I don't like new things gang". On the other hand it should stop there, k8s or swarm or whatever is not necessary for 90% of use cases or applications.