If your central IT knows anything about Automation / DevOps you should not be wrangling time with them at all. It is easy peasy to setup Jenkins/Ansible/Tower based self service workflow for automating deployment and other things. Most enterprise apps do not need autoscaling, or weird unsupported OSes and libraries - JVM and CLR solved that problem long time ago. If you did it right horizontal scaling any app server should be a piece of cake if and when that one time you actually need it.
If you do need specific OS versions/libs - just use plain old docker - that's much less complicated and at least serves a purpose.
The point I am trying to make is - very few classes of apps can benefit from the added complexity of K8S and you should carefully evaluate if your app can benefit from K8S specific features and your Developers/Ops team are ready to deal with the complexity they are signing up for.
Similarly, you're talking about a significant amount of work maintaining bespoke infrastructure duplicating what systems like Kubernetes, OpenShift, Nomad, etc. do but taking on the responsibility for integrating and supporting all of those disparate parts yourself, not to mention getting the policy, security, and operational go-ahead to do so.
“Easy peasy” does not match my experience with that approach but I'm glad it's working well for you.
> True but consider this - there used to be people whose job it was to do most of that stuff and the app developers did not have to think about it for the most part. Kubernetes/OpenShift just moved all of the complexity on the developer's plate - and the mind numbing stuff that results from that is worthy of few articles
Ignoring OpenShift, I don't think the comparison is quite that simple because it's leaving out all of the drawbacks from that traditional approach. Instead of writing a few lines of YAML you have to wrangle time and support from central IT, debugging is often a multi-party finger-pointing exercise with access limitations, and because you're talking about separate services and usually hardware changes and updates are hard because they need to be coordinated across multiple applications and teams.
That's not saying that there aren't legitimate areas for concern but I've seen fairly large amounts of developer time and downtime go into working around the limitations of that model (“<vendor> isn't compliant with this 15 year old RFC so we need to distribute forks of these 15 common tools for years until we can replace those $$$ appliances”).