У тебя есть идея. Простая, красивая идея. Допустим, сервис, который дёргает API погоды и присылает тебе в телеграм уведомление, если завтра дождь. Три эндпоинта. Одна база. Ты один.
И вот ты садишься писать код. Открываешь редактор. И думаешь: «А как это потом деплоить?»
Правильный ответ — взять VPS за пять долларов, закинуть туда docker-compose, настроить nginx, и пойти жить свою жизнь.
Но это же скучно. Это не масштабируется. Это не cloud-native. Так делали в 2015 году. Ты же современный инженер. Ты читаешь Hacker News. Ты знаешь, что правильная архитектура — это инвестиция в будущее.
И ты начинаешь.
Сначала Kubernetes. Нужен кластер. Managed слишком дорого, подымем свой на трёх нодах. Хотя нет, сначала надо выбрать CNI — Calico или Flannel? Потратил вечер на сравнение, выбрал Cilium, потому что у него eBPF и красивые графики.
Потом Helm. Потому что манифесты вручную писать — это не Infrastructure as Code. Нужны чарты. Нужен values.yaml. Нужен helmfile, чтобы управлять несколькими релизами. У тебя один релиз, но вдруг будет больше.
Ingress. Надо же как-то роутить трафик. nginx-ingress? Traefik? Istio? Давай Istio, там service mesh из коробки. Да, для трёх эндпоинтов. Зато будет observability.
Теперь observability. Prometheus для метрик. Grafana для дашбордов. Loki для логов. Jaeger для трейсинга. Потратил выходные на настройку. Дашборд показывает, что у тебя ноль запросов в секунду. Красиво показывает, с графиками.
CI/CD. GitHub Actions? Нет, это для простых. ArgoCD — вот это GitOps. Теперь у тебя коммит автоматически триггерит деплой в кластер. Кластер, в котором крутится один под с твоим приложением. Которое проверяет погоду.
Секреты! Чуть не забыл. Хранить секреты в переменных окружения — это небезопасно. Нужен Vault. Поднял Vault. Настроил интеграцию с Kubernetes. Теперь твой API-ключ от погодного сервиса хранится так же надёжно, как ядерные коды.
База данных. PostgreSQL? В Kubernetes? Нет, это сложно, stateful-приложения в k8s — боль. Надо managed. Взял managed PostgreSQL. Двадцать долларов в месяц. Для базы, в которой одна таблица с настройками.
Прошёл месяц. У тебя есть:
- Kubernetes-кластер на трёх нодах
- Service mesh
- GitOps-пайплайн
- Полный observability-стек
- Vault для секретов
- Managed база данных
- Красивые диаграммы архитектуры
У тебя нет:
- Работающего приложения
- Уведомлений о погоде
- Свободного времени
- Денег (инфраструктура жрёт под сотню долларов в месяц)
Это называется «resume-driven development». Ты строишь не продукт. Ты строишь строчку в резюме. «Проектировал и поддерживал cloud-native инфраструктуру на Kubernetes с service mesh, GitOps и полным observability-стеком». Звучит внушительно. На собеседовании спросят — расскажешь.
Проблема в том, что проект никогда не запустится. Потому что каждый раз, когда ты почти готов добавить фичу, появляется новая инфраструктурная задача. О, надо настроить автоскейлинг. О, надо добавить PodDisruptionBudget. О, надо обновить версию кластера.
А есть альтернативная вселенная. В ней ты взял тот самый VPS за пять долларов. Написал приложение на Python в сто строк. Закинул в Docker. Запустил через docker-compose. Настроил cron для перезапуска. Всё.
На следующий день ты уже получаешь уведомления о дожде. Проект работает. Ты можешь добавлять фичи. Можешь показать друзьям. Можешь забыть про него на полгода — он просто работает.
Когда у тебя будет миллион пользователей — тогда и будешь думать про Kubernetes. Спойлер: у пет-проекта не будет миллиона пользователей. И это нормально.
Есть такой принцип — YAGNI. You Ain't Gonna Need It. Ты не будешь это использовать. Автоскейлинг не нужен, если у тебя три запроса в день. Service mesh не нужен, если у тебя один сервис. GitOps не нужен, если ты деплоишь раз в месяц.
Но YAGNI не продаётся. На конференциях не рассказывают, как задеплоить приложение через scp. Курсов «Как запустить проект за вечер и пойти спать» не существует. Никто не напишет статью «Мы выбрали boring technology и ничего интересного не произошло».
Скажу крамольное: большинству проектов не нужен Kubernetes. Большинству проектов не нужен микросервисы. Большинству проектов нужен один сервер, один процесс, одна база.
Это не значит, что Kubernetes плохой. Kubernetes отличный. Для задач, где он нужен. Для highload. Для команд. Для систем, которые реально должны масштабироваться.
Но пет-проект — это не highload. Пет-проект — это чтобы работало. Чтобы ты увидел результат. Чтобы получить удовольствие от того, что создал что-то своё.
Инфраструктура — это не продукт. Инфраструктура — это налог на продукт. Чем меньше инфраструктуры ты можешь использовать — тем лучше. Потому что каждый компонент — это сложность. Это точка отказа. Это время на поддержку.
Лучший Kubernetes — это отсутствие Kubernetes.
В следующий раз, когда у тебя появится идея для пет-проекта — попробуй сначала запустить его максимально тупо. Без оркестрации. Без пайплайнов. Без mesh. Просто запустить и посмотреть, работает ли идея вообще.
А потом, может быть, ты поймёшь, что так оно и останется. И это будет означать, что проект — успешен.