Недавно на инфраструктурном митапе клуба Inview в ИТМО попросили поднять руки тех, у кого есть адекватная документация, которая соответствует проду. В большом зале подняли руки… четыре человека.

И вроде бы когда я на кастдевах спрашиваю, стоит ли проблема инвентаризации инфры / архитектурных диаграмм / сервисных карт - мне скучающим голосом перечисляют: CMDB, Grafana Service Map, DataDog, NetBox, Zabbix и т.д.

Столько всего есть, а актуальной документации нет. Как так?

В эпоху данных часто спрашивают: "А знаете ли вы, чем данные отличаются от информации?" Кажется, с этим мы уже разобрались.

Теперь хочется понять другое: чем инвентаризация отличается от документации? И почему у всех так много данных - но всё равно нет актуальной архитектуры As-Is?🔴

На одном из кастдевов мне посоветовали обратить внимание на DataDog. Это сервис мониторинга, который в том числе строит сервисные карты.

Я человек очень конкретный, поэтому мы с моей новой разработчицей Дарьей отправились в Дубай на выставку Gitex, чтобы пообщаться с представителями DataDog (и не только)😄

Один из вопросов, который меня интересовал: как отобразить на сервисной карте виртуалку, к которой нет доступа и потеряны все пароли.

Я думала в сторону того, чтобы не отображать связи вообще (всё равно время жизни такой виртуалки - до первого сбоя). Или показать только входящие стрелки. Или попробовать анализировать сетевой трафик... Но веселые сотрудники DataDog мне на это сказали, что в таком случае надо просто сделать brute force (иными словами хакнуть виртуалку).

Что думаете? Стоит ли включить функционал "хакнуть забытую виртуалку" в состав As-Is?))🔴

Получила на Хэллоуин благословление на свой инфра-стартап от Крестного отца DevOps @top1ceo🔥

Хороший знак?
Уверена, что да 🔴

В силу обстоятельств, о которых расскажу позже, мой фокус временно сместился с архитектуры по кнопке на деплой по кнопке.

В больших компаниях это уже решено: есть внутренние PaaS-платформы, где разработчик может развернуть сервис, базу или очередь буквально одним нажатием. В мире поменьше можно просто уйти в облако и жить на Heroku или его аналогах.

Но Heroku - это всё-таки чужая инфраструктура. Для команд со строгой СБ и чувствительными данными вариант "отдадим код в облако" даже не поднимается на обсуждение.

Сделать же свой PaaS - дорого, долго и требует сильной платформенной команды. В итоге многие застревают между двумя крайностями: облако нельзя, свой PaaS нереально.

И вот здесь становится интересно. На рынке уже появились решения для этого "между". Одно из них - open-source PaaS Coolify, который можно поставить на свой сервер и получить мини-Heroku под контролем компании.

Что делает Coolify:
- разворачивается на вашем сервере (VPS или физическом);
- использует Docker под капотом и превращает обычный сервер в маленький PaaS;
- подключаешь репозиторий из Git, описываешь, как запускать приложение - дальше сборку и деплой берёт на себя платформа;
- Postgres, Redis и прочие штуки поднимаются как готовые сервисы, а не отдельные "проекты по настройке";
- переменные окружения, логи, рестарты и health-check’и оказываются в одной понятной панели.

Для меня это ещё один пример того же паттерна, что и в истории с VictoriaMetrics: не всегда выигрывает тот, кто обещает "новый мир инфраструктуры". Очень часто побеждает тот, кто говорит: "Давайте ничего радикально не ломать. Сделаем почти то же самое, но с меньшей болью".

Это то, что в итоге должен сделать As-Is🔴

P.S. И да, хайповый n8n по кнопке в Coolify тоже есть))