CLUSTER
Немного исторической справки о том как появилась вся эта история с кластерами приложений и баз данных.
Да, в том числе это дает нам возможность. Но главная причина в том что нельзя вечно наращивать ресурсы конкретных узлов.
Раньше не было такого количество нагрузки и данных, поэтому хватало простых серверов парой ядер и парой гб оперативки. Все было хорошо.
Но со временем пришлось обрабатывать сильно больше трафика, и мы пришли к тому что даже самый мощных процессор с 96 ядрами 192 потоками уже перестает справляться. А еще для ускорения расчетов все больше начали использовать кеширование данных в RAM, все дошло до того что на одном сервере может не хватать и 1тб оперативки.
Кластерные решения стали единственным выходом. Теперь мы можем взять кучу средне мощных серверов и паралелить всю нагрузку на них. Получая хоть тысячи ядер и десятки терабайт оперативки)
Немного исторической справки о том как появилась вся эта история с кластерами приложений и баз данных.
Да, в том числе это дает нам возможность. Но главная причина в том что нельзя вечно наращивать ресурсы конкретных узлов.
Раньше не было такого количество нагрузки и данных, поэтому хватало простых серверов парой ядер и парой гб оперативки. Все было хорошо.
Но со временем пришлось обрабатывать сильно больше трафика, и мы пришли к тому что даже самый мощных процессор с 96 ядрами 192 потоками уже перестает справляться. А еще для ускорения расчетов все больше начали использовать кеширование данных в RAM, все дошло до того что на одном сервере может не хватать и 1тб оперативки.
Кластерные решения стали единственным выходом. Теперь мы можем взять кучу средне мощных серверов и паралелить всю нагрузку на них. Получая хоть тысячи ядер и десятки терабайт оперативки)
🔥2👍1
BILLING
В тему облаков.
В билинге ресурсов клатера бывают расходы которые сложно учесть с самого начала. К примеру:
- Внешний трафик
- Запросы в S3
- Возможный расширенный сапорт
Простой совет - заложить несколько процентов от цены ресурсов которые мы арендуем.
Совет посложнее - оптимизировать под реализацию клауда, например чаще внутренний трафик дешевле чем внешний. Можно еще кешировать файлы из S3.
Тут главное смотреть логи бюджета, там может быть много интересной инфы которая поможет снизить косты на ифру)
В тему облаков.
В билинге ресурсов клатера бывают расходы которые сложно учесть с самого начала. К примеру:
- Внешний трафик
- Запросы в S3
- Возможный расширенный сапорт
Простой совет - заложить несколько процентов от цены ресурсов которые мы арендуем.
Совет посложнее - оптимизировать под реализацию клауда, например чаще внутренний трафик дешевле чем внешний. Можно еще кешировать файлы из S3.
Тут главное смотреть логи бюджета, там может быть много интересной инфы которая поможет снизить косты на ифру)
👍1🔥1
STAND
Про разделение и конфигурацию стендов.
Самое простое это дев и тест стенды. Их вполне можно поднимать на одной общей инфре и давать более менее полные доступы командам разработки и тестирования. Главное это подлив данных для тестирования с прод стенда, важно их обезличивать.
На счет пре-прод стенда. В идеале он должен быть максимально близок к прод стенду, может только с меньшими ресурсами. Тут разграничение доступов должен быть более серьезным, что бы обеспечить тестирование близкое к реальным условиям.
Ну и на счет прода. Тут в идеале доступы должны быть только у инфровой команды, возможно у лидов команд. И чем он больше похож на препрод тем более качественные релизы мы можем выпускать)
Про разделение и конфигурацию стендов.
Самое простое это дев и тест стенды. Их вполне можно поднимать на одной общей инфре и давать более менее полные доступы командам разработки и тестирования. Главное это подлив данных для тестирования с прод стенда, важно их обезличивать.
На счет пре-прод стенда. В идеале он должен быть максимально близок к прод стенду, может только с меньшими ресурсами. Тут разграничение доступов должен быть более серьезным, что бы обеспечить тестирование близкое к реальным условиям.
Ну и на счет прода. Тут в идеале доступы должны быть только у инфровой команды, возможно у лидов команд. И чем он больше похож на препрод тем более качественные релизы мы можем выпускать)
👍1
SEC
Поверхность атаки.
С точки зрения системы это все что торчит наружу, и к чему имеет доступ внешний пользователь. Это может быть хоть vpn сервер для доступа к инфре, хоть эндпоинт авторизации в системе.
Если мы решаем сделать систему более устойчивой то начинать нужно именно с этого. Посмотреть до чего вообще можно дотянуться и попытаться эксплуатировать. Это может быть забытый порт приложения, или хардкод токена на фронте, что угодно.
Ну и хорошей идеей будет организовать ред тим внутреннию, которая сама попробоует атаковать нас как блекбокс. Чаще всего найдется что то интересное)
Поверхность атаки.
С точки зрения системы это все что торчит наружу, и к чему имеет доступ внешний пользователь. Это может быть хоть vpn сервер для доступа к инфре, хоть эндпоинт авторизации в системе.
Если мы решаем сделать систему более устойчивой то начинать нужно именно с этого. Посмотреть до чего вообще можно дотянуться и попытаться эксплуатировать. Это может быть забытый порт приложения, или хардкод токена на фронте, что угодно.
Ну и хорошей идеей будет организовать ред тим внутреннию, которая сама попробоует атаковать нас как блекбокс. Чаще всего найдется что то интересное)
👍1
K8S
Про главные плюс managed куба в облаке. Это возможность эксперементировать с параметрами нод.
У мен есть кластер в яндексе, на котором крутится под 200 подов. И стабильно раз в неделю - две я настраиваю новую группу нод с другой конфигурацией и перетаскиваю полезную нагрузку на нее, и дропаю старую.
Это позволяет в рамках одного бюджета на вычеслительные ресурсы подбирать более подходящие ресурсы. Например в недавней итерации перетащил все на AMD процы. Сейчас перетаскиваю на автоскейл группу. Иногда играюсь с соотношением CPU/RAM и уже вывел что для этого проекта идеальное соотношение 4gb RAM на 1 CPU.
И главное, это все делается без привешения бюджетов и без простоя. Кубер довольно умный, он может закардонить старые ноды и потионьку перебросить всю нагрузку на новые ноды)
Про главные плюс managed куба в облаке. Это возможность эксперементировать с параметрами нод.
У мен есть кластер в яндексе, на котором крутится под 200 подов. И стабильно раз в неделю - две я настраиваю новую группу нод с другой конфигурацией и перетаскиваю полезную нагрузку на нее, и дропаю старую.
Это позволяет в рамках одного бюджета на вычеслительные ресурсы подбирать более подходящие ресурсы. Например в недавней итерации перетащил все на AMD процы. Сейчас перетаскиваю на автоскейл группу. Иногда играюсь с соотношением CPU/RAM и уже вывел что для этого проекта идеальное соотношение 4gb RAM на 1 CPU.
И главное, это все делается без привешения бюджетов и без простоя. Кубер довольно умный, он может закардонить старые ноды и потионьку перебросить всю нагрузку на новые ноды)
👍2
AGENT
Инфра это последнее место куда бы я пускал AI.
Да, он сейчас хорошо пишет код, даже неплохие инфровые манифесты может написать. Но пускать агентов деплоить что то в прод пока рано. А особенно пускать в рут прод сервера и просить что то поправить)
Не спорю что современные AI модели очень умные, даже локальные. И можно дать агенту тулинг для дипсерча в интернете.
Но тут основной вопрос в архитектуре всей инфры в целом. Редко бывает что у нас всего один сервер и все завязано на него. А погрузить в агента всю архитектуру и документацию не так уж и просто, даже если построить раг и класть часть доки в системный промт то будет проблема с затуханием контекста. И в какой то момент модель может попытаться сделать что то, что находится вне запроса.
Ну и базово, страшно пускать на прод даже джунов, не то что блекбокс какой то)
Инфра это последнее место куда бы я пускал AI.
Да, он сейчас хорошо пишет код, даже неплохие инфровые манифесты может написать. Но пускать агентов деплоить что то в прод пока рано. А особенно пускать в рут прод сервера и просить что то поправить)
Не спорю что современные AI модели очень умные, даже локальные. И можно дать агенту тулинг для дипсерча в интернете.
Но тут основной вопрос в архитектуре всей инфры в целом. Редко бывает что у нас всего один сервер и все завязано на него. А погрузить в агента всю архитектуру и документацию не так уж и просто, даже если построить раг и класть часть доки в системный промт то будет проблема с затуханием контекста. И в какой то момент модель может попытаться сделать что то, что находится вне запроса.
Ну и базово, страшно пускать на прод даже джунов, не то что блекбокс какой то)
👍1
TMP
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
Вынесение шаблонов деплоя в отдельную репу может сильно ускорить релизы.
Да, не всегда просто сделать такой шаблон который учтет все возможные варианты. Но разово настроив мы можем быстро подрубать к новым микросервисам шаблон и быстро катить. Останется только заполнить переменки.
Ну и есть два типа добавления шаблонов.
1. Подключаем как include нужные модули, в самом CI/CD манифесте.
2. Переобределяем дефолтный путь до пайплайна на внешнюю репу.
Чаще удобнее второй вариант, но первый дает возможность нам включать только то что нужно.
👍1
SHARED
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
Иногда мы делаем какую то общую инфру для разных проектов. Что бы условно 3 разные команды с своими проектами могли использовать общую дев/тест инфру.
Тут главное реализовать это инфру так что бы никто никому не мешал. Важно заложить:
- Команде доступен только свой неймспейс
- Для всех отдельные пользаки в БД с своими лимитами коннектов
- Определенный ресурс для каждой команды, исходя из ее потребности
- Разделение доступов до логов и метрик, что бы не было общей помойки
С этими базовыми вещами для каждой команды сможем выделять изоированный кусок общей инфры, так что бы они не мешали друг другу)
👍1
TMP
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
Сейчас пишу шаблоны пайплайнов для нового проекта. Там по классике несколько микросервисов которые нужно выкатить.
Люблю новые проекты, там можно сразу применить весь свой опыт и сразу сделать хорошо)
Пока реализовал уже два шаблонных шага:
- Билд jar файла
- Билд и паблиш образа с этим jar файлом
Делаю максимально униврсальные стейджи пайплайна которые можно просто импортировать в проект и оно само поедет)
👍2
TEAM
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
Ща собираем стенд для одного проекта. И это один из редких опытов когда нас на проекте двое девопсов.
Процесс мы выстроили таким образом: Раз в какое то время синкуемся с командой разработки и понимаем глобальную задачу. Создали борду где нарезаем большие задачи на небольшие, из разряда "написать шаблон чарта", "поднять кластер", "написать джобу сборок".
Нарезаем задачи таким образом что бы не блокировать друг друга и можно было делать их в любом порядке.
Ну и что то около кросс ревью, когда смотрим задачи друг друга)
Это редкий момент когда можно так поработать, а не как обычно в одиночку)
👍2
NET
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
Кратенько о том как я настраиваю сетевые политики для нод кластера, для яндекс клауда:
1. Все ноды без белого IP
2. Разрешение всего инпута в контексте локальной сети
3. Вес аутпут через дефолтный nat клауда
4. Все ноды в свое изолированной сети
Это позволяет пускать трафик на ингрес через сетевой балансер и нормально взаимодействовать всем компонентам кластера. Ну и учитывая что это изолированная локалка к самим нодам напрямую никто не сможет обратится, только через апи и по правилам сетевого балансера.
Такой подход дает приемлимый уровень безопасности и позволяет не сильно усложнять сетевые политики)
👍1
WALL
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
Один из способов защиты от DDOS атак это делегирование защиты на специализированные системы.
Как пример можно взять cloudflare. По сути защита там реализованная как обычный балансировщик нагрузки, мы просто включаем DNS в режими проксирования и весь трафик к нашему сайту будет идти сначала через cloudflare.
В базовой версии они берут на себя защиту от DDOS и подобых атак.
Что важно понимать при настройке: cloudflare ставит свой ssl сертификат который отдает пользователям, и по дефолту шлет запросы в нашу систему по http. Что бы настроить ssl между cloudflare и нами нужно для начала сделать сами серты и потом включить настройку ssl full уже на cloudflare.
👍1
PROD
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
Что в идеале надо настраивать на прод стенде, после того как сам проект релизится туда из теста:
- Отключаем дебаг
- Отключаем свагер, актуатор и прочие вещи связанные с разработкой
- Наружу открываем только реально нужные порты, чаще только 80 и 443
- Убеждаемся что наружу не торчит какой то левый урл
Важно понимать, что все что мы делаем ради удобства тестирования и разработки может стать поверхностью атаки на проде)
👍1
JUMP
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Дальше просто подрубаемся так:
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
Ssh over jump сервер. Это один из способов тунелирования ссш трафика.
Допусти у нас есть один сервер с внешним ip, к которому у нас есть доступ, и куча серверов внутри сети без прямого доступа с локальной машины.
Допустим мы хотим попасть на сервер из этой внутренней сети. Как это можно решить:
По сути одним простым конфиг файлом для ssh.
Host external-host
HostName some_ip
User root
Host internal_host
HostName some_ip
User ops
ProxyJump external-host
Дальше просто подрубаемся так:
ssh internal_host
Таким образом трафик сначала пойдет на external-host и оттуда уже на internal_host.
👍1
BILING
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
Про неочевидные траты в клауде.
Иногда забывается - в клауде мы платим не только за сами ресурсы но и за операции. Например в S3 бакете мы платим не только за пространство, но и за PUT/GET операции. Проблема в том что из за этого может вырасти расход, даже при небольшом количество данных.
Например какой либо сервис при мисконфигуре может разогнаться и начать слать тысячи запросов к бакету, и по итогу мы будем оплачивать все. Да, одна операция почти ничего не стоит, но если их тысячи в секунду и длиться несколько часов то сумма может выйти большой.
👍1
TMP
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
Допустим у нас есть несколько одинаковых джоб в гитлабе, допустим для деплоя на разные стенды. Как это сделать красивее? Сделать шаблон и завязываться на него, просто конфгурируя.
Как пример:
.deploy:
stage: deploy
image: docker:19.03.8-dind
script:
- ./deploy.sh
tags:
- docker
environment:
name: $CI_COMMIT_BRANCH
deploy_prod:
extends: .deploy
variables:
BRANCH: master
HOST: prod
only:
- master
deploy_dev:
extends: .deploy
variables:
BRANCH: dev
HOST: dev
only:
- dev
Тут мы сделали общий шаблон .deploy, где есть вся общая настройки джобы и мы завязываемся на него через extends. Удобно и красиво)
👍2
SSDLC
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
Не самая очевидная мысль - жизненный цикл кода заканчивается когда его удаляют с прода.
Из этого следует что безопасность надо проверять не только на этапе разработки но и на проде. Но тут есть хитрый трюк)
Когда мы разрабатываем новые фичи то по пайплайну проходит вообще весь код прложения, и сканировать можно прям вообще все приложение а не только изменения. Таким образом мы проверяем и то что сейчас на проде.
НО, это не отменяет того что на проде может быть легаси которые мы не обновляем, и соотвественно по пайплайну с проверками этот код не проходит. Поэтому от проверок всего прода мы не уйдем, просто трюк с проверкой всего при разработке делает уже сильно лучше)
👍1
GITLAB
Хочется немного пожаловаться на систему бекапирования гитлаба.
Сделать полноценный бекап можно только через встроенный механизм гитлаба - gitlab-backup create. И как он работает:
- Создает архивы с дампом всех компонентов по отдельности
- Все эти бекапы формирует в один большой архив
То есть по сути если у нас все данные гитлаба веся 250гб то сначала создаться несколько больших файлов гигов на 200 и потом они сохраняться в один большой файл на те же 200гб. Итого нам надо что бы диск машины был хотя бы гигов в 700.
Это довольно неудачное решение как по мне, так как придется постоянно держать диск занятым не более чем на треть, и платить за 2/3 диска которые почти все время будут простаивать.
Да, в этом есть логика, возможно дробить дампы по компонентам в чем то удобнее, но с точки зрения потребления места это очень больно.
Хочется немного пожаловаться на систему бекапирования гитлаба.
Сделать полноценный бекап можно только через встроенный механизм гитлаба - gitlab-backup create. И как он работает:
- Создает архивы с дампом всех компонентов по отдельности
- Все эти бекапы формирует в один большой архив
То есть по сути если у нас все данные гитлаба веся 250гб то сначала создаться несколько больших файлов гигов на 200 и потом они сохраняться в один большой файл на те же 200гб. Итого нам надо что бы диск машины был хотя бы гигов в 700.
Это довольно неудачное решение как по мне, так как придется постоянно держать диск занятым не более чем на треть, и платить за 2/3 диска которые почти все время будут простаивать.
Да, в этом есть логика, возможно дробить дампы по компонентам в чем то удобнее, но с точки зрения потребления места это очень больно.
👍1
GITLAB
Сейчас занимаюсь переездом с одного инстанса гитлаба на другой, с новым доменом и полностью новой инфрой.
Какие основные сложности могут возникнуть:
- Диск. Тот же прикол что и с бекапированием, о котором вчера писал, с рестром бекапа та же история
- Конфигурация. Для того что бы все нормально переехало нужно воссоздать конфигурацию на 100 процентов такую же как на старом гитлабе
- Время. Большую часть времени ты просто ждешь, спустя пару часов может просто появится ошибка, и придется все делать с начала
- Раннеры. После рестора почти гарантировано придется делать новые раннеры
- Домены. Тут могут возникнуть проблемы в CI/CD если не была заявязка на переменные с адресами
В остальном, это хорошее время что бы взять техработы и настроить все как надо)
Сейчас занимаюсь переездом с одного инстанса гитлаба на другой, с новым доменом и полностью новой инфрой.
Какие основные сложности могут возникнуть:
- Диск. Тот же прикол что и с бекапированием, о котором вчера писал, с рестром бекапа та же история
- Конфигурация. Для того что бы все нормально переехало нужно воссоздать конфигурацию на 100 процентов такую же как на старом гитлабе
- Время. Большую часть времени ты просто ждешь, спустя пару часов может просто появится ошибка, и придется все делать с начала
- Раннеры. После рестора почти гарантировано придется делать новые раннеры
- Домены. Тут могут возникнуть проблемы в CI/CD если не была заявязка на переменные с адресами
В остальном, это хорошее время что бы взять техработы и настроить все как надо)
👍1
FRONT
Сейчас появляется модный паттерн проектирования фронтенда - микрофронты.
Логика тут в целом как и на бекенде, максимадно разделяем функциональность по разным приложениям. В контексте фронта у нас есть какой то основной индекс, который делает запросы на разные фронтовые ресурсы, а мы уже роутим эти запросы на нужные микрофронты.
Под копотом у таких фронтов может быть что угодно, хоть ssr на ноде хоть просто статика на nginx.
Логика тут такая же как и на беке:
- Распределение нагрузки
- Скейл только нужной функциональности
- Отказоустойчивость
На практике пока очень редко это видел. Но все больше обсуждается такой подход)
Сейчас появляется модный паттерн проектирования фронтенда - микрофронты.
Логика тут в целом как и на бекенде, максимадно разделяем функциональность по разным приложениям. В контексте фронта у нас есть какой то основной индекс, который делает запросы на разные фронтовые ресурсы, а мы уже роутим эти запросы на нужные микрофронты.
Под копотом у таких фронтов может быть что угодно, хоть ssr на ноде хоть просто статика на nginx.
Логика тут такая же как и на беке:
- Распределение нагрузки
- Скейл только нужной функциональности
- Отказоустойчивость
На практике пока очень редко это видел. Но все больше обсуждается такой подход)
👍1