Когда Terraform становится тесным: как Pulumi превращает инфраструктуру в программный продукт

Когда приложение состоит из одного app.py, жизнь кажется удивительно простой. Открываешь терминал, запускаешь tail -f, смотришь несколько строк логов и довольно быстро понимаешь, что происходит. Ошибка подключения к базе данных выглядит как ошибка подключения к базе данных. Исключение в коде находится ровно в том месте, где его выбросили. Если что-то сломалось, виновник обычно обнаруживается быстрее, чем успевает остыть кофе. Именно поэтому многие инженеры годами живут с ощущением, что логов достаточно для любых задач наблюдаемости.

А потом приложение начинает расти.

Интернет задумывался как глобальная сеть, в которой любой компьютер может связаться с любым другим компьютером. На практике всё давно работает немного иначе. Где-то провайдер режет определённые сервисы, где-то появляются ограничения на отдельные протоколы, где-то плохо работает международная маршрутизация, а иногда нужный ресурс оказывается недоступен просто потому, что находится за пределами привычного маршрута вашего трафика. В результате даже опытный инженер периодически сталкивается с ситуацией, когда нужная документация не открывается, очередной релиз на GitHub скачивается со скоростью почтового голубя, пакеты PyPi становятся недоступными, Telemost начинает заикаться в голосовых каналах, а какой-нибудь зарубежный сервис внезапно оказывается недоступен из-за особенностей маршрутизации или региональной политики доступа.

Одной из причин, почему роль инфраструктурного тимлида регулярно становится объектом шуток внутри технических команд, является различие в природе результатов труда. Работа инженера предельно осязаема. Если DevOps-инженер автоматизировал разворачивание окружений через Terraform, результат можно увидеть в репозитории, протестировать и использовать. Если специалист по эксплуатации внедрил систему наблюдаемости, то через несколько часов в Grafana появляются новые панели мониторинга, а в Alertmanager - уведомления о сбоях. Если команда внедрила GitOps-подход и перевела развёртывание сервисов под управление Argo CD, это отражается на скорости доставки изменений и снижении количества ошибок при релизах. Результаты инженерной работы фиксируются в коде, конфигурациях, метриках и работающих сервисах. Они измеримы, воспроизводимы и заметны окружающим.

Когда человек впервые слышит аббревиатуру IDM, обычно происходит одна из двух вещей.

Разработчик делает умное лицо и произносит: "А, Identity Management...". Инфраструктурщик же тяжело вздыхает, потому что мгновенно вспоминает очередной ночной инцидент, в ходе которого выяснилось, что бывший сотрудник, уволившийся ещё несколько месяцев назад, по-прежнему может подключиться к production через старый VPN. А если повезёт особенно сильно, то у него ещё обнаружится действующий Jenkins token, забытый kubeconfig и сервисный аккаунт, который когда-то создавался "буквально на пару дней".

И именно в этот момент становится понятно, что IDM - это не про логин и пароль.

Еще несколько лет назад разговоры о замене VMware воспринимались как попытка сэкономить ради самой экономии. Практически в любой крупной компании можно было услышать один и тот же аргумент: "VMware дорогой, зато надежный". Инфраструктурные команды привыкли к знакомым инструментам, процедуры эксплуатации были отлажены годами, а сам гипервизор казался чем-то настолько фундаментальным, что его замена выглядела почти невозможной. Однако изменения на рынке заставили многие организации пересмотреть эти убеждения. Рост стоимости лицензий, ужесточение условий использования и усиливающаяся зависимость от одного поставщика сделали вопрос миграции не теоретическим, а вполне практическим.

Сразу хочется сделать одно важное уточнение. Всё, что будет написано ниже, не является рекламой и не претендует на абсолютную объективность. Это взгляд инженера, который успел поработать с разными вариантами эксплуатации Kubernetes - от полностью самособранных кластеров на базе kubeadm до платформенных решений, внедрённых в крупных корпоративных инфраструктурах. Это опыт человека, который обновлял кластеры в рабочее время и восстанавливал их ночью, спорил с отделами информационной безопасности, искал причины деградации сети между площадками и объяснял бизнесу, почему фраза "просто обновите Kubernetes" на практике редко оказывается простой задачей. Среди этих решений был и Deckhouse, поэтому дальнейший рассказ основан не на презентациях и маркетинговых материалах, а на наблюдениях, сделанных во время реальной эксплуатации.