Привет! Меня зовут Евгений, я Lead DevOps в EXANTE. В статье расскажу о том, что получилось, когда мы решили быстро стать Cloud Native и запихнули всё подряд в Kubernetes. Вы узнаете, какие ошибки мы допустили, как они отразились на скорости разработки и релизах, и почему теперь мы смотрим на инфраструктуру совсем иначе.

EXANTE — это брокерская компания с собственной трейдинговой платформой. Через неё можно торговать на более чем 50 рынках по всему миру с единого мультивалютного счёта. Наши основные клиенты — профессиональные трейдеры и институциональные инвесторы. Наши сервисы очень разные: от лёгких приложений до тяжёлого легаси со statefulset’ами на десятки CPU и сотни гигабайт памяти, долгим стартом (15+ минут) и огромными кешами на PVC.

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

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

Ожидания: стать Cloud Native

В конце 2023 года мы с руководством сформулировали цели:

• Наш продукт становится Cloud Native.

• Инфраструктура легко развёртывается в любых облаках.

• Финансы становятся прозрачными — мы хотим понимать, за что платим и где дороже.

• Сокращается time to market новых фич.

На тот момент у нас был настоящий зоопарк технологий: OVH и HTZ, Avela, managed-сервисы в GCP и AWS. У каждой технологии были свои правила и ограничения, поэтому управление зоопарком было похоже на дрессировку стаи диких животных.

Далее я расскажу про GCP, потому что там мы допустили больше всего ошибок.

Реальность

Мы хотели ускорить time to market. У нас был Terraform, Chef для VM, Flux CD для GitOps. Вроде всё звучало красиво - мигрируем сервисы в GKE и получаем моментальный профит, и мы решили: перевозим в GKE даже legacy.

Среди сервисов были монстры:

• statefulset’ы на 36 CPU и 70 GB RAM,

• startup time 15+ минут, кэши, скачивающиеся при старте приложения по 25-30 GB на PVC и необходимость периодически чистить PVC,

• protobuf в чистом виде, стриминг, костыли.

И мы подумали: «Да нормально, Kubernetes всё вывезет». Но результат оказался примерно таким:

• Замедлился time to market. Команды разработки и тестирования не были готовы перестраивать пайплайны под GKE.

• Усложнились релизы. Релиз-инженеры были шокированы количеством ручных шагов и долгого старта сервисов.

• Снизилась утилизация ресурсов. На старте взрывное потребление, потом резкое падение.

• Пострадал GitOps. Flux CD банально задыхался, если деплоить больше шести тяжёлых сервисов одновременно. Queue, зависания, ручное вмешательство.

• Усложнился анализ инцидентов. Новая инфраструктура — новая боль для девов и саппорта.

• Поломалась коммуникация. DevOps’ы требовали изменений в коде сервисов, а разработчики справедливо говорили: «У нас продуктовый roadmap, мы не можем сейчас выделить полкоманды на рефакторинг ради инфраструктуры».

Какие выводы мы сделали

Наше стремление к Cloud Native оказалось самурайством ради самурайства. Мы гнались за быстрыми результатами, но без долгосрочного плана инфраструктурные quick wins превратились в hard fails. И вот, что мы поняли:

• Стратегия важнее хайпа. Kubernetes — инструмент, а не самоцель, и не всё legacy нужно в него тащить. Есть сервисы, которые проще и дешевле оставить вне Kubernetes и автоматизировать их развёртку там.

• Инфраструктура ≠ DevOps-игрушка. Это часть продукта, при изменении которой нужно учитывать планы разработки и бизнеса. DevOps и разработку важно синхронизировать: миграция сервисов должна идти рука об руку с их развитием.

Ошибки и болезненные эксперименты в начале пути заставили нас остановиться и перестроить мышление. В итоге факап стал для нас точкой роста. Теперь мы чётко понимаем: Cloud Native — это не запихнуть всё в Kubernetes, а нащупать баланс между техническим драйвом, здравым смыслом и реальной ценностью для бизнеса.

Infrastructure 2.0: перезапускаем платформу

К проекту Infrastructure 2.0 мы подошли более зрело и прагматично. У него есть сроки, роадмап, ответственные, а главное — задачи с реальным value для продукта и команды. Это не миграция ради миграции, а внятная стратегия развития, где каждое решение обосновано. Сейчас мы находимся в процессе её внедрения.

1. Сеть и фундамент

Начали с самого уязвимого места — сетевых связей. Раньше любой сбой отзывался по всей системе. Поэтому мы внедряем устойчивые интерконнекты между OVH и облаками (AWS/GCP) с BGP/OSPF/BFD.

Второй шаг — распределённый Consul Cluster: это «единый справочник сервисов». Благодаря ему Kafka, наши инфраструктурные и другие сервисы будут находить друг друга по консистентным DNS-именам, а не через костыли.

2. DevOps-платформа

• Flux CD показал нам свои пределы. Мы внедряем ArgoCD, чтобы получить прозрачность и предсказуемость. Разработчики смогут видеть деплои, тестировщики — откатывать изменения, а ApplicationSet позволит поднимать временные окружения за минуты.

• Istio выбрали не случайно: нам нужен единый вход, mTLS по умолчанию и контроль доступа на уровне сети.

• Karpenter добавляем для автоматического управления нодами: чтобы система сама понимала, когда и сколько ресурсов нужно.

• Nomad готовим для легаси, которое не хочется ломать. Это компромисс: контейнеры без боли Kubernetes.

3. Требования к разработке

Для разработки мы вводим единые правила: контейнеры, stateless, JSON-логи и Prometheus-метрики. Каждый сервис должен иметь паспорт и runbook. Может показаться бюрократией, но на деле это избавление от хаоса. Теперь разработчики будут идти по рельсам, а DevOps перестанут тонуть в исключениях.

4. Наблюдаемость и финансы

Мы внедряем полный сбор метрик и FinOps-дашборды. Пилотные отчёты уже показывают, что некоторые сервисы съедают в разы больше ресурсов, чем мы думали. Это позволяет нам закладывать экономику заранее.

5. Безопасность

Безопасность - всегда была с нами, но теперь мы выводим ее на новый уровень.

• Везде mTLS (через Istio).

• Централизованный Vault.

• Базовые Docker-образы проходят ревью SecOps.

• Образы сканируются AquaSecurity.

6. Операции и инциденты

Мы готовим DR-окружение в GCP. Секреты и GitOps-состояния будут синхронизироваться автоматически. Документация и runbooks пишутся параллельно, чтобы команды могли работать по инструкции, а не по наитию.

Что нам даст Infrastructure 2.0

Переход на Infrastructure 2.0 — результат не только инженерной работы, но и культурной трансформации: прозрачность, зрелость, ориентация на реальное value. Это системное изменение подхода к проектированию, развитию и поддержке инфраструктуры.

И вот его ключевые принципы:

• Скорость и гибкость. Теперь мы можем быстро поднимать feature-окружения, тестировать гипотезы и откатывать изменения без недельных согласований. Это напрямую сокращает time-to-market и даёт разработке больше свободы.

• Надёжность и отказоустойчивость. У нас есть горячий standby в GCP, автоматическая синхронизация секретов и GitOps-состояния, а значит — даже серьёзный инцидент не парализует бизнес.

• Прозрачность затрат. FinOps-дашборды позволяют видеть, какие сервисы и окружения реально потребляют ресурсы, и принимать взвешенные решения — где оптимизировать, а где вкладываться.

• Удобство для разработки. Стандарты на метрики, логи, переменные окружения и универсальные Helm-чарты снимают хаос и снижают порог входа. Новый сервис теперь можно запустить по готовым рельсам, а не изобретать велосипед.

• Безопасность по умолчанию. mTLS, централизованный Vault, проверенные базовые образы и политика ротации секретов закрывают многие уязвимости ещё до того, как они попадают в прод.

• Накопление знаний. Runbooks, документация и регулярные пост-мортемы формируют базу знаний, которая помогает новым людям быстро включаться, а опытным инженерам — не наступать на старые грабли.

И главное — мы перестаём воспринимать инфраструктуру как расходный ресурс. Для нас это полноценный продукт, который должен быть удобен для бизнеса, разработки, саппорта и SecOps. Мы уверены, что он позволит нам быстрее выводить новые фичи, минимизировать стоимость простоя, снижать расходы за счёт прозрачного управления ресурсами, и, самое важное — создавать платформу, которая растёт вместе с бизнесом, а не тормозит его.

И да, Kubernetes в этой картине по-прежнему важен. Но теперь это не путь самурая, а часть стройной экосистемы, где каждая технология занимает своё место и работает на общую цель.

Следите за нашими успехами в следующих статьях — впереди ещё много экспериментов, поражений и побед!