4 ms·

I think that aspect is indirectly covered, as one of the main motivation was to get on a popular platform that helps hiring. I agree on how it's technically a

I think that aspect is indirectly covered, as one of the main motivation was to get on a popular platform that helps hiring. I agree on how it's technically a waste of time to pursue fads, but it's also a huge PITA to have a platform that good engineers actively try to avoid, as their careers would stagnate (even as they themselves know that it's half a fad)

sangnoir 2y ago
I avoid working at organisations with NIH syndrome - if they are below a certain size (i.e. they lack a standing dev-eng team to support their homegrown K8s "equivalent"). Extra red flags if the said homegrown-system was developed by that guy[1] who's ostensibly a genius and has very strong opinions about his system. Give me k8s' YAML-hell any day instead, at least that bloat has transferable skills, amd I can actually Google common resolutions. 1. Has been at org for so long, management condones them flaunting the rules, like pushing straight to prod. Hates the "inefficiency" of open source platforms and purpose-built something "suitable for the company" by themselves, no documentation you have to ask them to fix issues because they don't accept code or suggestions from others. The DSL they developed is inconsistent and has no parser/linter.
- fragmede 2y ago
  yeah. If you think Kubernetes is too complicated, the flip side of that is someone built the simpler thing, but then unfortunately it grew and grew, and now you've got this mess of a system. you could have just used a hosted k8s or k3s system from the start instead of reinventing the wheel. absoutely start as simple as you can, but plan to move to a hosted kube something asap instead of writing your own base images, unless that's a differentiator for your company.