На первый взгляд и вправду похоже на MFE! Но у нас не классический module federation/iframe-подход. Скорее это «виджетная модель» поверх одного хост-приложения. Соответственно, такие компоненты подключаются как независимые через ленивую загрузку: если виджет не фигурирует в конфигурации страницы, его код вообще не попадает в итоговый бандл. Границы отказа держим на уровне реализации виджетов: у каждого есть своё состояние, свои fallback’и.
За счёт единого билда и общего runtime мы избегаем типичных для module federation историй с размазыванием версий и shared-зависимостей. Гибкость и расширяемость достигаются за счёт конфигурации и контрактов между фронтом и бэкендом, а не за счёт набора разнесённых remote-бандлов. Т.е., по сути это контролируемая композиция и ленивое подключение компонентов на уровне виджетов, но не MFE в строгом, инфраструктурном смысле.
Ну и дисклеймер на всякий случай: такой подход не является «серебряной пулей» и подойдёт не всем, но в нашем случае выбранная модель хорошо покрывает текущие потребности по масштабированию, отказоустойчивости и управляемости, мы вполне осознаём её границы и возможные зоны роста.
Готовые решения могут быть выходом, но подойдут ли — зависит от ваших требований и задач. В нашем случае они всех наших требований не покрывали. Поэтому мы начали смотреть в сторону разработки собственной архитектуры на базе Next.js с выделенным BFF и рассчитывали, что такой подход
ускорит разработку,
позволит масштабировать команду без ограничений, распределяя разработчиков по отдельным виджетам.
Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.
Спасибо за вопрос! На самом деле, никто не спорит с тем, что хороших инструментов существует великое множество. У большинства профессионалов не возникнет проблем ни с Messos, ни с Nomad, ни с libvirt-lxc 🙂 Весь вопрос в том, кто принимает решение об использовании инструмента, и для каких целей мы подбираем этот инструмент 😉
Если один отдельно взятый человек (возьмём для примера автора этой статьи) захочет в личных целях развернуть 10 микросервисов, то наверняка выберет какой-то более экзотический инструмент, чем Kubernetes — как минимум, просто потому что это интересно.
Но если мы ставим целью минимизировать затраты на поддержку и поиск специалистов, выбор с большой вероятностью падёт именно на кубер. Просто потому это уже давно де-факто стандарт в индустрии.
Привет! Мы тестировали ovn-bgp-agent, но решили его не запускать по нескольким причинам.
1. Не удалось полноценно разделить сервисный и клиентский трафик.
2. Несовместимость текущей версии openstack и той версии, которую мы запустили.
3. Как следствие, отсутствие достаточного тестирования перед вводом в продакшн.
В сторону OVN Fabric Integration смотрели — перспективно, но выглядит пока сыро, код еще дописывается. Подход в обновлении площадок у нас довольно консервативен и не совпадает с возможностью запуститься на последней версии, которая на несколько релизов свежее текущей.
Тесты c ovn-bgp-agent по трафику не проводили. Проблемы с высоким irq тоже пока не ловили.
Ньюанс с sr-iov — это ограничение на количество сетевых интерфейсов, а значит, и на количество ВМ на гипер.
Возможно, имеет смысл использовать для aaS сервисов, a DPDK для gateway нод.
Привет! Мы сменили вектор на Openstack для нивелирования рисков использования зарубежного ПО, а также для возможности дальнейшей поставки в контур собственных сервисов, которые уже работают на этом стеке.
Но мы действительно опустили множество деталей, чтобы не превращать статью в перечисление нормативных требований. Если подробности интересны, мы постараемся раскрыть их в дальнейшем.
Спасибо за вопрос! Это наш пятый кластер, и у нас уже есть команда опытных специалистов по openstack, его компонентам и интеграциям. Если говорить о размерах, то только один из наших кластеров — это примерно 25K vCPU и около 10K VM.
Здравствуйте! Всё так и есть, как вы говорите — если нарисовать «развесистую схему», то никто ничего не поймет и смысла в ней не будет. В статье мы как раз попытались рассказать, как этого избежать. В конце концов, UML — это только средство общения: кому-то он подходит, а кому-то нет. Например, стартапу, в котором всего три разработчика (и они же его основатели), то любое документирование будет казаться пустой тратой времени, потому что основатели и так свою систему знают до последней запятой. Другое дело, если перед нами большая корпорация, где есть несколько команд и люди периодически меняются. Тогда и нужен тот самый общий язык, чтобы у новичка хотя бы была возможность куда-то подсмотреть и понять, что сделали до него. Рунити — не гигантская корпорация, но нам UML как раз в похожих случаях помогает.
Как написали выше, у 19 версии в первую очередь лучше стабильность и производительность OSD. Основная цель нашего апдейта сейчас — изменения/фиксы в RGW и OSD. Фичи — это попозже.
Если не секрет, что за диски вы используете?
У нас Intel/Solidigm TLC
Какие формулы берете за основу?
Формула для SLA стандартная: (Общее время − Время простоя) / Общее время × 100%. Для SLA 99.95% допустимый простой в месяц — около 21 минуты. Цифры берем исходя из скорости аварийного поднятия инфраструктуры при тестировании и не берем в расчет выход компонентов (деградированное состояние кластера). У нас есть отдельное соглашение об SLA, если интересно: https://img.reg.ru/faq/SLA_18032025.pdf
На первый взгляд и вправду похоже на MFE! Но у нас не классический module federation/iframe-подход. Скорее это «виджетная модель» поверх одного хост-приложения. Соответственно, такие компоненты подключаются как независимые через ленивую загрузку: если виджет не фигурирует в конфигурации страницы, его код вообще не попадает в итоговый бандл. Границы отказа держим на уровне реализации виджетов: у каждого есть своё состояние, свои fallback’и.
За счёт единого билда и общего runtime мы избегаем типичных для module federation историй с размазыванием версий и shared-зависимостей. Гибкость и расширяемость достигаются за счёт конфигурации и контрактов между фронтом и бэкендом, а не за счёт набора разнесённых remote-бандлов. Т.е., по сути это контролируемая композиция и ленивое подключение компонентов на уровне виджетов, но не MFE в строгом, инфраструктурном смысле.
Ну и дисклеймер на всякий случай: такой подход не является «серебряной пулей» и подойдёт не всем, но в нашем случае выбранная модель хорошо покрывает текущие потребности по масштабированию, отказоустойчивости и управляемости, мы вполне осознаём её границы и возможные зоны роста.
Готовые решения могут быть выходом, но подойдут ли — зависит от ваших требований и задач. В нашем случае они всех наших требований не покрывали. Поэтому мы начали смотреть в сторону разработки собственной архитектуры на базе Next.js с выделенным BFF и рассчитывали, что такой подход
ускорит разработку,
позволит масштабировать команду без ограничений, распределяя разработчиков по отдельным виджетам.
Наши ожидания оправдались☺
Привет, спасибо за советы! Это мы изучим.
Привет, спасибо)
Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Смотря какой и смотря зачем — финал всё равно всегда проверяют разработчики перед коммитом.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Привет! Добавили расшифровку в самое начало, но если вы ощущаете себя станцией технического обслуживания, мы принимаем ваш выбор.
В нашем случае акцент был сделан на простоте и готовности решения — Ollama уже использовалась в другом нашем недавнем продукте с ИИ-ассистентом.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Можно ли ответить популярной гифкой?
Например, для того, чтобы собрать инфраструктуру из 10 инстансов.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.
Спасибо за вопрос! На самом деле, никто не спорит с тем, что хороших инструментов существует великое множество. У большинства профессионалов не возникнет проблем ни с Messos, ни с Nomad, ни с libvirt-lxc 🙂 Весь вопрос в том, кто принимает решение об использовании инструмента, и для каких целей мы подбираем этот инструмент 😉
Если один отдельно взятый человек (возьмём для примера автора этой статьи) захочет в личных целях развернуть 10 микросервисов, то наверняка выберет какой-то более экзотический инструмент, чем Kubernetes — как минимум, просто потому что это интересно.
Но если мы ставим целью минимизировать затраты на поддержку и поиск специалистов, выбор с большой вероятностью падёт именно на кубер. Просто потому это уже давно де-факто стандарт в индустрии.
Привет! Мы тестировали ovn-bgp-agent, но решили его не запускать по нескольким причинам.
1. Не удалось полноценно разделить сервисный и клиентский трафик.
2. Несовместимость текущей версии openstack и той версии, которую мы запустили.
3. Как следствие, отсутствие достаточного тестирования перед вводом в продакшн.
В сторону OVN Fabric Integration смотрели — перспективно, но выглядит пока сыро, код еще дописывается. Подход в обновлении площадок у нас довольно консервативен и не совпадает с возможностью запуститься на последней версии, которая на несколько релизов свежее текущей.
Тесты c ovn-bgp-agent по трафику не проводили. Проблемы с высоким irq тоже пока не ловили.
Ньюанс с sr-iov — это ограничение на количество сетевых интерфейсов, а значит, и на количество ВМ на гипер.
Возможно, имеет смысл использовать для aaS сервисов, a DPDK для gateway нод.
Здравствуйте! Если не секрет, почему у вас сложилось такое впечатление?
Привет! Мы сменили вектор на Openstack для нивелирования рисков использования зарубежного ПО, а также для возможности дальнейшей поставки в контур собственных сервисов, которые уже работают на этом стеке.
Но мы действительно опустили множество деталей, чтобы не превращать статью в перечисление нормативных требований. Если подробности интересны, мы постараемся раскрыть их в дальнейшем.
Спасибо за вопрос! Это наш пятый кластер, и у нас уже есть команда опытных специалистов по openstack, его компонентам и интеграциям. Если говорить о размерах, то только один из наших кластеров — это примерно 25K vCPU и около 10K VM.
Здравствуйте! Всё так и есть, как вы говорите — если нарисовать «развесистую схему», то никто ничего не поймет и смысла в ней не будет. В статье мы как раз попытались рассказать, как этого избежать. В конце концов, UML — это только средство общения: кому-то он подходит, а кому-то нет. Например, стартапу, в котором всего три разработчика (и они же его основатели), то любое документирование будет казаться пустой тратой времени, потому что основатели и так свою систему знают до последней запятой. Другое дело, если перед нами большая корпорация, где есть несколько команд и люди периодически меняются. Тогда и нужен тот самый общий язык, чтобы у новичка хотя бы была возможность куда-то подсмотреть и понять, что сделали до него. Рунити — не гигантская корпорация, но нам UML как раз в похожих случаях помогает.
Как написали выше, у 19 версии в первую очередь лучше стабильность и производительность OSD. Основная цель нашего апдейта сейчас — изменения/фиксы в RGW и OSD. Фичи — это попозже.
У нас Intel/Solidigm TLC
Формула для SLA стандартная: (Общее время − Время простоя) / Общее время × 100%. Для SLA 99.95% допустимый простой в месяц — около 21 минуты. Цифры берем исходя из скорости аварийного поднятия инфраструктуры при тестировании и не берем в расчет выход компонентов (деградированное состояние кластера). У нас есть отдельное соглашение об SLA, если интересно: https://img.reg.ru/faq/SLA_18032025.pdf