Посоветуйте idM решения и продукты. Нужно 100к юзеров и 100к машин централизованно контролить. Не винда.

🙏

В 5-летней ретроспективе неплохие были продукты. Возможно сейчас есть и лучше.

Я бы поискал forgerock vs something

oracle

Который будет доставлен в РФ только в warhead? Спасибо, не надо

о чем вы? холодная война давно закончилась

Добрый ночи, коллеги.
Облачно ХайЛоад когда большое количество запросов. У меня же запросов немного, но ответ должен прийти быстро за Х мс 90 процентиль. Какие в этом случае могут быть узкие места? Что можно почитать на эту тему.

Каждое дополнительное взаимодействие, особенно сетевое - будет узким местом.
Хотя мс - это много

Мы просто завидуем

Из общего можно про теорию массового обслуживания

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BC%D0%B0%D1%81%D1%81%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D1%81%D0%BB%D1%83%D0%B6%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

В целом, долгое время занимался именно такими системами, и хайлоад в современном понимании как-то не впечатляет, он несколько про другое.
Два направления могу сходу выделить - исключение лишних звеньев во взаимодействии (два обращения к сокету, потому что сеть на докере? Убираем к чёрту. Задержка на переключении контекста процессора, потому что несколько кристаллов? Прибиваем процесс гвоздями к кристаллу. Вот вплоть до такого, да.) и построение асинхронных конвейеров (стремление к неблокирующему параллелизму)

Читать не знаю что, всё подряд, это в основном старые знания, а не современные. Дискретная математика, оптимизация циклов и вычислений, ленивые вычисления.
После чего применять не на уровне программизма, а на уровень системы или группы систем, если архитектор.

в рамках хайлоада о таких вещах если и рассказывают, то очень редко, поверхностно и вскользь, я бы сказал что для совсем начинающих, вот например. Но снова, упор больше на "и запросов тоже немало"

https://www.youtube.com/watch?v=CvT1v7xiRS0

2000 участников

Узкие места могут быть примерно везде, поэтому почитать нужно примерно всё.

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

Ну... если сравнивать ИТ архитекторов и обычных, то получается, что в ИТ тогда архитекторами можно назвать только технических (и то с оговорками), а остальных типа EA и SA - нет. Т.к. архитектор (классический, который про здания и струтктуры) это инженер, чуть менее, чем полностью. Гауди, Эйфель они фигачили чертежи, дизайн, выбирали материалы конструкций, ключевые элементы итд много сугубо технических вещей. И их совершенно не волновало, какие там на стройке процессы, как же проарабы между собой договориваются, какое там взаимодействие у застройщиков, как организованна коммуникация команд электромонтажников с арматурщиками, никаких бизнесовых и организационных процессов, т.к. к архитектуре они никакого отношения не имеют. Архитектура это фасады сагрда фамилия и причудливая система колонн, архитектура это сложное переплетениее стальных балок и арочных перекрытй, делающих эфелеву башню узнавемой и новаторской в своё время. И переодический контроль, что строители дейтсвуют по чертежам т.е. авторский надзор, и это всё вообще никак не связанно с внутренней организацией застройщиков, подрядчиков. Это не рисование цветных кубиков, как жеж бригаде А получить данные от бригады Б.
Кстати гауди сначала таки выполнял черновые работы - мелкие чертежи, оградки и фонари, т.е. начал с джуна чертёжника.
(лучше не сравнивать в общем, слишком разная специфика, имхо)

А Solution Architect здесь при чем? Вполне практическая роль. А вот EA, да. Вообще вся идея EA базируется на глубоком upfront design и экономии за счет повторного использования. Мы тут кубики целевой архитектуры нарисовали, а дальше задача решить в какой кубик добавлять новый функционал. Такой подход можно уже смело похоронить.

Это тривиальное разделение ответственности между архитекторами и строителями, которое законодательное закреплено в некоторых странах. Насколько, я помню, например, во Франции.

Благодарю за расширенный ответ. Я системный аналитик, требования к времени ответа в целом от бизнеса, к отдельным компонентам от нашего архитектора, основное микросервисы в OpenShift. Сейчас пока функциональное тестирование, смотрим что в принципе работает правильно. На тестовом контуре сильно не укладываемся во время, профилирование пока не проводится, работаем над основной функциональностью.
Можно предположить, что на тесте слабое железо, но хотелось бы разобраться комплексно. Понимаю, что конкретные тайминги покажет только профилирование

Хм.. С чего бы это... Кажется есть повод задуматься...