Фил, что такое с твоей точки зрения Kubernetes?

Оркестратор контейнеров.

С кучей плохих архитектурных решений почти в каждой точке и очень дорогой для внедрения и сопровождения.
Работает только при наличии команды специалистов и куче дополнительного софта.
Без поддержки за вменяемые деньги.

Из потенциальных плюсов - платформа для сервис-меша и некоторых других концепций.

Твои слова во многом справедливы

Эм, немного поделюсь своим текущим опытом. У нас есть BusArc и SolArch. И кажется, мне только кажется, что для разного уровня развития компаний требуется разная работа на этих позициях.

Но рассмотрим BA. Смотря на текущую ситуацию он занимается сопровождением больших проектов от начала до конца. Тут важно отметить, что сложность проектов должна быть высокой или может быть вариант с направлением, которое имеет несколько больших проектов. В рамках этих проектов, в компании большой, но не громадной (навроде СБТ) превалирует полевая работа (договорённости, описание процессов, ведение технической документации вплоть до уровня техрешения) над структурной (систематизация, определение стандартов, прочего). Но с определённого момента, при росте сложности в системе, работа по систематизации увеличивается. Точной границы я не знаю, т.к. бизнес-архитекторов на таком уровне я не видел.

Кто туда может идти? Человек обладающий пониманием путей развития своей IT компании, знающий метрики доходности, способный взвесить возможные доходы/расходы, договориться на высшем уровне о старте/остановке проекта. Важно понимать интересы партнёров и законы рынка. Естественно там куча прикладных умений должно быть (свойственных для аналитиков, продажников, продуктологов и отчасти управленцев), но в целом нужно владеть более высоким уровнем абстракции о работе предприятия (уровня директора или чуть ниже).

Главное штаны не протирать занимаясь маранием бумаги и систематизацией/стандартизацией всего и вся. Основная задача - принести/сэкономить деньги, а уже потом оптимизировать процессы (опять же сэкономить деньги).

Вот как-то так это видится с моей точки зрения.

а какие там плохие архитектурные решения?

Но какие есть альтернативы для решения тех же задач, при условии, использования контейнерой виртуализации?

Докеры, DNS, автоскейлинг, логи

Заметка.
Делаем виртуализацию, абстрагироваться от железа.
Делаем контейнеры,  абстрагироваться от операционной системы (*).
Делаем jvm-based приложение, которое в том числе абстрагирует от операционной системы.

Найти лишнее в этой истории очень легко. Никто не делает.

А какие задачи решаем? Если просто поднять-опустить виртуалки, то ansible+виртуалки вполне нормально заходит.
Или та же vSphere. Или даже Mesos (хотя он тоже так себе).

Ну, мы делаем. У нас простенькая запускалка jvm-ок и управление ими. И свой сервис-меш (тупой и простой).
И пофиг на железо, оркестрации и т.п.

Звёздочка значит что на макоси и винде недодокер

Вы редкие. И я рад за вас.

(Просто старые...)

ну докеры там опциональны, kubedns тоже. Чем плох автоскейлинг? Про какие вы логи говорите?

Автоскейлинг плох тем, что в нем нет смысла )
Логи - подход кубера к логам контейнеров.

Да-да. Делаем управление виртуалками (chief, puppet, ansibl...)
Делаем управление контейнерами (swarm, k8s)..

Нет реальных задач для автоскейлинга, если ты не амазон или Яндекс.

Удваиваю. Железо само собой не скейлится. Для большинства корпората - это процесс закупок