В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится 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 в других паттернах, буду рада услышать
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится 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 в других паттернах, буду рада услышать
Но обычно история про deploy отделена от истории про API.