Бэкенд между облаками, соединяете вручную?
Florete — защищенный сервис-меш из коробки
Сервисам в распределённом бэкенде нужно безопасно общаться между облаками и on-prem. Florete делает это нативно — mTLS и Service Discovery работают как часть самой сети.
Сложный стек для связи между сервисами
У архитектора на разработку networking-решения уходят его время и бюджет команды. Для DevOps каждый проект начинается со сборки кастомного стека, который потом надо поддерживать.
- 01В каждом проекте — стек из четырёх систем: Vault для CA, Consul для discovery, WireGuard для транспорта и собственная обвязка, которая всё это согласовывает. Каждая система со своей операционной нагрузкой.
- 02Заказчик требует доказать, что межсервисный трафик зашифрован и аудируется. Самописная связка через ИБ-ревью проходит с трудом: нет понятной модели угроз, нет единого журнала доступа, размытое владение сертификатами.
- 03Передача проекта в поддержку: объяснить заказчику, кто отвечает за ротацию сертификатов и что случится в три ночи при истечении CA — отдельная задача, на которой проект может застрять при сдаче.
- 01Кастомное управление PKI:
cert-managerв k8s,cfsslна VM, скрипты для on-prem — три разных flow для одной и той же задачи. Каждый раз молимся, что ротация сертификатов не уронит ничего ночью. - 02Service Discovery и транспорт — это два разных слоя. Consul знает, что сервис где-то есть, но не знает, как до него физически добраться, если он за NAT в другом облаке. Связность между локациями приходится решать отдельно — VPN, peering, статические маршруты.
- 03Каждое новое окружение — снова настраивать всю связку. Разные облачные провайдеры, NAT, разные сети у заказчиков — каждый раз первая неделя уходит на инфраструктурный «холодный старт».
Готовый сервис-меш вместо ручной сборки
Vault, Consul и WireGuard решают свои задачи хорошо — но каждую по отдельности. Во Florete идентичность, шифрование и транспорт — это части самой сети, спроектированной для распределённого бэкенда между локациями.
mTLS между локациями как сетевой примитив
Агент Florete сам устанавливает mTLS-соединения между сервисами в разных облаках и on-prem. Не нужен отдельный VPN снизу и отдельный Vault сверху.
Один CA для всей инфраструктуры
Сертификаты выдаются и ротируются автоматически. Срок жизни короткий, ротация невидимая. Нет «ой забыли продлить» и нет cron'а на скриптах.
Service Discovery и Load Balancing — вишенка на торте
Сервисы общаются по именам вида customer-db.client.rete независимо от их локации и IP-адресов. То, ради чего обычно ставят отдельный Consul.
Как это выглядит у DevOps
API в Yandex Cloud, база заказчика on-prem, аналитика на edge. Сервисы общаются между локациями по именам, под защитой mTLS, с одной автоматической PKI. Управление через стандартный GitOps-воркфлоу: конфигурация в YAML, раскатывается в control plane одной командой florctl publish.
nodes: app-yc: { addresses: ["udp://10.128.0.5:7700" ] } bank-on-prem: { addresses: ["udp://10.50.1.5:7700" ] } analytics-spb: { addresses: ["udp://91.185.0.22:7700"] } # user nodes - dynamic IPs devops-laptop: { }
services: core-api: { at: app-yc, upstream: "::1:8080" } customer-db: { at: bank-on-prem, upstream: "::1:5432" } reports-api: { at: analytics-spb, upstream: "::1:9000" } # Florete control plane service, deployed on-prem florcp: { at: bank-on-prem, upstream: "::1:4433" }
$ florctl validate ✓ Config valid: 13 nodes, 8 services, 6 roles $ git commit -am "add analytics-spb to mesh" $ git push $ florctl publish ✓ Published to mesh control plane: florcp.mybank.rete
$ florctl status mesh control plane ✓ OK (on-prem) nodes: app-yc ✓ OK (yandex cloud) bank-onprem ✓ OK (on-prem) analytics-spb ✓ OK (edge dc) ✓ certs: auto-rotated 6h ago, next in 18h
Расскажите про вашу инфраструктуру — мы покажем демо.
Hands-on от основателей: ставим, конфигурируем, остаёмся на связи в общем чате. Тридцать минут разговора — и вы поймёте, подходит ли Florete под вашу ситуацию.
Self-serve регистрация появится после релиза MVP в 2027 году. Сейчас — только живой разговор.