Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).
В целом внутри тоже REST. Ибо внутренние разработчики — они тоже разработчики. HTTP проще отлаживать, проще кодить. Синхронное взаимодействие в целом легче понимать. Но, конечно, есть обстоятельства, когда гарантии доставки (от использования очередей) оказываются более значимыми чем удобство использования.
Есть сценарии, в которых используем очереди. Но это глубоко внутренние сценарии. С моей точки зрения, общение по REST проще в сопровождении и быстрее. Кроме того, простота REST для нас критична как для платформенного решения — представьте семинар по пользованию АПИ, где вы объясняете через POSTMAN collection, и семинар, где вы объясните асинхронную модель и работу с очередями. :) Если что-то для внешних пользователей можно упростить, то это всегда нужно упростить.
оба варианта, как мне кажется, имеют одинаковую сложность. Но в одном случае сложность имплементируется в коде, а во втором — в deployment схеме. Помните знаменитую картинку про микросверисы: сложность в коде vs сложность в связях?
Вы ранее назвали HTTP/gRpc стандартом общения микросервисов, а это значит что общение происходит синхронно(request/response), хотя для поддержания низкой связности всякие event-driven подходы считаются предпочтительнее.
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
Интересно было бы узнать, независимый ли у микросервисов цикл релизов друг от друга, и сколько сил/времени занимает координация релизов, она ведь всё-равно нужна иногда.
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
J2ee, кажется, ограничено Java-ой? А задачи Wamp-а не соответствуют задачам Kubernetes?
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.
>>7 бед — один кубернет. И с ним уже 8 бед.
Намекаете на то что мысль выше — верна? Ок, спасибо.
kubernetes как ответ на вопрос «как потом деплоится такое приложение?». под «распределённый монолит взаимодействующий по сети» Вы имеете в виду сильную связность сервисов?
я бы сказал что история про deploy перекликается с историей про обратную совместимость
Безусловно, чтобы обновить API нужно раздеплоить новую версию компонента. Но, Евгений, кажется, я не улавливаю Выше мысль. Развернете?
Думаю, под «нерешаемой» проблемой скалирования/масштабирования вы имели ввиду «ограниченно решаемую»? Ведь наплодить потоков со своими дубликатами данных в рамках одного адресного пространства — дело несложное, но возникает ограничение размерами физической ноды.
Rust — это хорошая история, но, кажется, тогда всю серверную разработку прийдется переводить с Go на Rust, а это достаточно трудоемко. Вы используете Rust у себя? Можете поделиться опытом?
В монолитах свои проблемы с API. Текущие абстракции (leaky abstractions). Спинлоки, торчащие из интерфейсов, для производительности. Переменные с разделяемым доступом. Неструктурированные, но такие уютные и привычно-домашние интерфейсы, в которых любой посторонний ногу сломит.
Я нежно люблю монолиты за их скорость, но программный интерфейс между подсистемами внутри монолита нельзя называть сильной стороной этого паттерна
Не возникало ли у Вас в процессе мысли о том что проблем было бы меньше если бы использовалось не RESTAPI а более строгая спецификация?
Мысли что-то улучшить рождаются постоянно. Ограничивает обычно время, ресурсы и здравый смысл про лучшее враг хорошего. Но давайте обсудим про более строгие спецификации. Вы имеете в виду GraphQL или что-то другое? И какие плюсы Вы сами в них видите?
А если RESTAPI, то в ее модификации купно с HATEOAS?
Те сервисы Акронис, которые используют мультимедиа контент, следуют рекомендациям HATEOAS. Если у Вас есть позитивный опыт применения HATEOAS в других паттернах, буду рада услышать
Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Ну часть историй отваливается все же. Область ответственности у младшего императора меньше чем у старшего. Иначе бы он был старшим.
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.
kubernetes как ответ на вопрос «как потом деплоится такое приложение?». под «распределённый монолит взаимодействующий по сети» Вы имеете в виду сильную связность сервисов?
Безусловно, чтобы обновить API нужно раздеплоить новую версию компонента. Но, Евгений, кажется, я не улавливаю Выше мысль. Развернете?
Я нежно люблю монолиты за их скорость, но программный интерфейс между подсистемами внутри монолита нельзя называть сильной стороной этого паттерна
Мысли что-то улучшить рождаются постоянно. Ограничивает обычно время, ресурсы и здравый смысл про лучшее враг хорошего. Но давайте обсудим про более строгие спецификации. Вы имеете в виду GraphQL или что-то другое? И какие плюсы Вы сами в них видите?
Те сервисы Акронис, которые используют мультимедиа контент, следуют рекомендациям HATEOAS. Если у Вас есть позитивный опыт применения HATEOAS в других паттернах, буду рада услышать