Я до сих пор помню гробовое молчание в зале для совещаний. Наш технический директор только что объявил, что мы отказываемся от Kubernetes после двух лет плотной работы и инвестиций. Никто не решался задать первый вопрос. Мы выстроили всю инфраструктуру на K8s, обучили команду… и теперь — снова разворот. Всё по-новой.
И как оказалось, мы были вовсе не одиноки.
В тени громких конференций и без пафоса презентаций происходит тектонический сдвиг. Компании, ещё недавно провозглашавшие Kubernetes «святым граалем» контейнерной оркестрации, теперь тихо ищут альтернативы. И речь не о стартапах из подвала — речь о крупнейших игроках, чьи облачные архитектуры выросли на Kubernetes как на фундаменте.
Справедливости ради: Kubernetes никуда не исчезнет в одночасье. Его экосистема огромна, а за спиной — Cloud Native Computing Foundation. Он глубоко внедрён в сотни компаний. Но трещины уже появились, и шёпот сомнений превращается в гром.
После десятков разговоров с инженерами и изучения инфраструктурных трендов я начал понимать, почему это происходит. И какие технологии приходят на смену. Картина, которая сложилась, оказалась неожиданной — даже для меня.
Переломный момент: почему компании переосмысливают Kubernetes
Сложность, которая себя не оправдывает
Идея казалась блестящей: универсальный способ развёртывать, масштабировать и управлять приложениями в контейнерах. А на практике — кривизна обучения, сравнимая с отвесной скалой.
«Мы тратили больше инженерных часов на поддержку кластеров Kubernetes, чем на разработку новых фичей», — признаётся старший инженер из единорога, который недавно отказался от K8s. — «Рано или поздно ты спрашиваешь себя: а оно того стоит?»
Этот вопрос всё чаще звучит по обе стороны океана. Термины вроде pods, services, ingress, CRD и бесконечные YAML-файлы требуют от команды умственной гибкости, которая редко бывает оправдана.
Инженерный директор из одного Fortune 500 прямо заявил: «38% времени нашей DevOps-команды уходит на устранение проблем с Kubernetes вместо улучшения пайплайнов. Это неустойчивое соотношение».
Скрытый центр затрат
Kubernetes преподносится как инструмент, позволяющий сэкономить ресурсы за счёт оптимального распределения. Но всё сложнее.
Сертифицированные инженеры по K8s стоят дорого. Кластеры приходится избыточно резервировать под пиковые нагрузки. Управление control plane в облаке тоже требует ресурсов. В итоге суммарная стоимость владения выходит выше изначальных ожиданий.
Один техлид из SaaS-компании признался: «Мы думали, что объединив микросервисы в Kubernetes, будем экономить. Через полгода счёт за облако вырос на 25%. И это без учёта дополнительных наймов».
Несовпадение зрелости
Самая недооценённая проблема — Kubernetes требует архитектурной зрелости, которой у многих организаций просто нет. Он отлично работает с правильно выстроенными микросервисами, но не с монолитами в контейнерах.
«Мы внедрили Kubernetes, не подготовив архитектуру», — признался CTO, отказавшийся от K8s. — «В итоге мы получили всю сложность, но ни одной выгоды. Это была худшая из возможных комбинаций».
Что приходит на смену: 5 альтернатив, набирающих обороты
1. AWS App Runner и ECS: простота вместо контроля
Amazon предлагает два сервиса: ECS — старичок в контейнерной оркестрации, и более свежий App Runner, который почти полностью скрывает технические детали.
Компании всё чаще комбинируют их: App Runner для простых приложений без состояния, ECS — для более гибких сценариев. Один VP по инженерии делится: «После перехода с EKS на связку App Runner + ECS мы сократили издержки на инфраструктуру на 60%».
Минус — меньше контроля. Но многим хватает функционала, чтобы забыть о YAML и наслаждаться продуктивной разработкой.
2. Nomad: недооценённый оркестратор
HashiCorp тихо развивал Nomad в тени Kubernetes, и теперь он выходит на свет. Простая архитектура, поддержка не только контейнеров, но и обычных приложений, batch-задач.
«Nomad дал нам 80% возможностей Kubernetes за 20% сложности», — рассказал архитектор из компании, уставшей от K8s. Интеграция с Vault и Consul делает Nomad частью цельной экосистемы.
Особенно полезен он для тех, кто ещё не полностью перешёл на контейнеризацию.
3. Serverless-контейнеры: Cloud Run и Azure Container Apps
Модель serverless контейнеров — настоящая противоположность Kubernetes. Вы отдаёте образ контейнера — всё остальное делает платформа: масштабирование, маршрутизация, инфраструктура.
«Мы мигрировали 70% микросервисов с GKE на Cloud Run», — говорит директор платформенной инженерии. — «Теперь деплой занимает одну команду, а не десятки YAML-файлов».
Минус — ограниченный контроль над сетями и хранилищами. Но для stateless-приложений этого почти не чувствуется.
4. Внутренние платформы: абстракция над Kubernetes
Некоторые компании оставляют Kubernetes, но скрывают его за «внутренней платформой» — собственной системой, упрощающей жизнь разработчику.
Backstage, Humanitec, Porter — яркие примеры. А кто-то создаёт кастомные платформы под свои нужды.
«Мы оставили Kubernetes, но наши разработчики о нём не знают», — делится тимлид из крупной компании. — «Деплой — это кнопка. Всё остальное — забота платформенной команды».
Решение требует вложений, но улучшает Developer Experience кратно.
5. Минимализм: контейнеры без оркестрации
Пожалуй, самый неожиданный тренд — возвращение к простоте. Контейнеры запускаются напрямую на виртуалках с помощью Docker Compose или systemd. Без оркестраторов.
«Мы поняли, что используем кувалду, чтобы забить канцелярскую кнопку», — честно говорит CTO одного стартапа. — «Наши приложения не требуют динамического масштабирования. Нам хватает автоматизации, мониторинга и здравого смысла».
Именно такие решения всё чаще выбирают небольшие команды, которым не нужно деплоить 50 раз в день.
Как понять, что Kubernetes — не для вас
Универсального рецепта нет. Но вот пять признаков, что вам стоит посмотреть по сторонам:
- Масштаб. У вас сотни микросервисов по всему миру? Тогда да, Kubernetes оправдан. Если же приложение компактное — скорее всего, нет.
- Ресурсы команды. Есть ли у вас инженеры платформ, готовые жить в YAML-джунглях? Если нет — K8s будет перегрузом.
- Реальные потребности. Нужны ли вам автоскейлинг, продвинутые ingress, QoS и affinity? Или всё можно решить проще?
- Частота деплоя. Если вы выкатываете изменения раз в неделю — зачем вся эта махина?
- Инвестировано ли уже в K8s? Если да, возможно, проще абстрагировать его, чем менять инфраструктуру.
Будущее оркестрации: многообразие вместо монополии
Похоже, маятник качнулся обратно в сторону простоты. Всё больше команд понимают: сложность Kubernetes не всегда оправдана.
Это не означает конец эры Kubernetes, но его монополия ослабла. Он становится инструментом для специфических сценариев, а не универсальным решением.
Скорее всего, рынок разделится: крупные корпорации останутся на Kubernetes, а те, кто хочет быстрого вывода продукта на рынок и меньше операционной боли — выберут лёгкие альтернативы.
Главное — не бояться задавать себе неудобные вопросы. Даже после многих лет инвестиций.
Иногда единственный способ расти — это отступить на шаг и признать: стандарт отрасли — не всегда стандарт, подходящий лично вам.
***✨ А что думаете вы? ✨
Делитесь мыслями в комментариях — ваше мнение вдохновляет нас и других!
Следите за новыми идеями и присоединяйтесь:
• Наш сайт — всё самое важное в одном месте
• Дзен — свежие статьи каждый день
• Телеграм — быстрые обновления и анонсы
• ВКонтакте — будьте в центре обсуждений
• Одноклассники — делитесь с близкими
Ваш отклик помогает нам создавать больше полезного контента. Спасибо, что вы с нами — давайте расти вместе! 🙌