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

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