Horchestra: когда Kubernetes нельзя, а Ansible становится второй кодовой базой

Значимый прорыв формирует отрасль ИИ: ckpunT 29 минут назад Horchestra: когда Kubernetes нельзя, а Ansible становится второй кодовой базой Средний 14 мин 451 DevOps * Информационная безопасность * Системное администрирование * Open source * Последние три года я занимаюсь разработкой и поставкой enterprise-продуктов. И относительно недавно понял одну вещь. Самая сложная часть проекта — вовсе не разработка.

Самая сложная часть — доставка и поддержка. Пока приложение работает на ноутбуке разработчика, всё выглядит прекрасно. Собрали, запустили, прогнали тесты, отправили изменения в Git.

Технические детали

Проблемы начинаются в тот момент, когда продукт нужно поставить заказчику. И тут оказывается, что единого способа поставки не существует. У одного заказчика уже есть Kubernetes, и достаточно передать Helm‑чарт.

У другого контейнеры запрещёны требованиями ИБ. Третий принципиально использует только RPM‑пакеты. Четвёртый работает исключительно на Alt Linux.

Пятый — на РЕД ОС и Astra. Шестой до сих пор живёт на CentOS 7, потому что обновление инфраструктуры — отдельный многолетний проект. Иногда разрешены контейнеры.

Отраслевые последствия

Иногда разрешены, но есть нюанс. Иногда наоборот — запрещены любые контейнерные рантаймы. И чем больше становится заказчиков, тем сильнее начинаешь понимать одну неприятную вещь: проблема уже давно не в том, как написать приложение.

Проблема в том, как доставить одно и то же приложение во все эти совершенно разные инфраструктуры. А потом это ещё и поддерживать. Две кодовые базыДавно заметил интересную закономерность.

Практически каждый enterprise-продукт начинает жить сразу в двух кодовых базах:Собственно приложение — исходный код, бизнес-логика, тесты. Инфраструктурный код — всё, что отвечает за установку, настройку и обновление. И очень часто именно вторая начинает расти быстрее первой.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.