Конспект

Я решил обсудить этот вопрос по следующим причинам:

1. Первая причина. Пётр просил стандартизировать процесс доставки приложений на прод. Отличная идея. И, чтобы этот стандарт устраивал всех, здесь присутствуют все, кто на практике или в теории заинтересованы в этом. Заинтересованы, значит предъявляют или могут предъявить свои требования к стеку.
2. Вторая причина. Были предъявлены разные требования к приложениям, которые собираются на стеке Node.js. Владимиру было сказано, что мы должны поставлять приложения в виде докер-контейнеров (наверное, имелись ввиду докер-образы с соответствующими конфигурациями контейнеров, верно?) Мне было сказано, что приложения должны поставляться в виде исходного кода.

Я думаю, самое время определиться, что мы будем с этим делать.

Что мы имеем на данный момент: если грубо, то инфраструктуру виндовых машин, которая управляется ТимСити. Верно?

Как выяснилось, со слов Петра, это накладывает свои ограничения на удобство и эффективность развёртывания стека, отличного от дотнет, когда речь идёт о развёртывании этих приложений в окружениях хост-машин. А всякие эти ваши докеры становятся чуть ли не аппендиксом. Потом поправьте меня, если я что-то упустил.

А теперь вопросы, которые я хочу здесь поднять:

1. Стек. Должны ли все остальные подстраиваться под существующий стек? Назовите хотя бы одну причину. Возможной такой причиной является следующий вопрос:
2. Технические ограничения. Категорически не согласен с Петром. У нас нет таких технических ограничений. Что мешает завести в нашу экосистему одну или несколько линуксовых машин и отдать под контроль ТимСити? Это почти риторический вопрос. Поэтому я хочу иметь возможность выбирать произвольное поставляемое окружение из доступных и стабильных.
3. Докер. Зоопарк технологий неизбежен. Наиболее эффективный способ сэкономить ресурсы и время в борьбе с ним, - докер. Эта технология обеспечивает поставку приложения на хост-машину со всем необходимым ему окружением. Это же идеальный вариант. И, самое главное, это наиболее предсказуемый, наиболее контролируемый и наиболее простой вариант. Вопрос - почему команда админов этому сопротивляется?
4. Шаринг технологий и инфраструктуры между командами. Как показывают мои наблюдения, каждая не дотнет команда имеет свой девопс, в котором почти не участвует наша команда админов. Самый жёсткий случай - команда Димы, которая подняла кубернетис для собственных нужд. Я ковырял как-то куб, и чуть не сошёл с ума. Представляете, какой это оверхед и какие издержки, если мы будем заниматься девопсом, а не писать код. Я отчасти могу понять позицию виндовых админов. Это чуждый для них стек. И чисто в профессиональном плане, возможно, они не видят перспективы его осваивать. Так же я спросил мнения знакомых бэкендеров, не посвещая их в детали, целесообразно ли вешать ли на одну команду два почти не пересекающихся стека. Единогласно мне ответили, что нормальных виндово-линуксовых админов не бывает, и есть смысл не напрягать людей работой, которая им не по душе. Это разные миры. Исходя из этого, следующий вопрос:
5. Вакансия линукс админа. Нам нужен человек, которому мы сможем доверить нужную нам экосистему. Она будет не менее важна, чем дотнет.