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.
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.