>We need to promote learning and mastering the underlying concepts
Should we do the same thing for programming languages? Make sure people are learning and mastering assembly?
>Only to be stuck with a solution that requires constant care and work around.
I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough". Like the shell scripts didn't require constant care..
> I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough".
That attitude is also quite myopic.
Not to condescend, but if one isn't working on cloud-native apps in federated environments then maybe maybe maybe one should be intellectually humble enough to allow that there are some challenges people face that make "good enough" a non-starter, prohibitively expensive, or require direct competition with AWS/MS/Google in their core competencies.
Everything is a spectrum. Serious work can be done on a single server with no backups... Shell scripts can carry serious work far... Ansible or Docker Swarm rock for what they are... but the multi-cloud orchestration platform we're discussing rocks a oodles of things those solutions aren't.
Well it is a good thing I did not suggest shell scripts, ansible or puppet. I suggested owning it stack. Which means wiring code and tools to suite your needs.
Deployment and upgrades should be built in - as in it is part of your product. Not some afterthought.
It's odd how the two replies have read have jumped to conclusions about what one might use if they were not using kubernetes.
Perhaps if you shared some more concrete detail about what it means to "own the stack" people would be less inclined to fill in the blank in a way you hadn't intended to communicate?
> Deployment and upgrades should be built in - as in it is part of your product. Not some afterthought.
Kubernetes is one of several products that offer environment agnostic mechanisms to handle deployment and upgrades.
If you're dealing with hundreds of 'products', or a mountain of microservices, or large batch job scheduling, putting the lot of it on Kubernetes is addressing deploying, upgrading, monitoring, securing, discovering, and many other things up front in a shared, consistent, and portable manner.
A forethought, not an afterthought...
I agree that owning your core systems is valuable. Focusing on core IT competencies and business value creation are more valuable, though, and if you're not dealing with multi-cloud-platform resource management I can't imagine how to justify writing tools that compete with established, mature, industry standard solutions. You're always better to focus on your unique advantages and competencies... If you're ok using an RDBMS system in your stack, then using a scheduling/upgrading framework should be pretty ok, too.
Should we do the same thing for programming languages? Make sure people are learning and mastering assembly?
>Only to be stuck with a solution that requires constant care and work around.
I've seen this attitude from people who didn't want to use ansible/chef/puppet because their shell scripts were "good enough". Like the shell scripts didn't require constant care..