Очень интересно.
С точки зрения логики все должно быть так, но я как раз вокруг себя вижу противоположную картину. Люди, которые раньше не особенно вовлекались в работу, с невысоким уровнем личной ответственности (как правило <L5) и без «огня в душе» часто очень громко говорят, как им нравится удалёнка, какой у них жизненный баланс наладился, а волосы стали гладкими и шелковистыми.
А вот условные синьоры, лиды и выше поголовно вешаются от удалёнки и считают дни до возвращения в офис, т.к. поддерживать высокий уровень вовлечения и продуктивно взаимодействовать в команде стало на порядок тяжелее.
Понятно, что оба подхода имеют право на существование и никто не обязан быть фанатиком на работе, но все же рассказы про продуктивность частично звучат как самообман.
Просто у тех, кто раньше не вовлекался в работу теперь есть возможность поддерживать лучший баланс (особенно на фоне того, что руководителям/старшим товарищам вовлекать их стало сложнее). Ну и, само собой, должен быть процент супер-дисциплинированных людей с особым mindset-ом, на кого это правда позитивно повлияло (даже в долгую), но кажется что таких людей в целом немного.
Со стороны ваше утверждение выглядит так:
У нас есть сугубо организационная проблема ограничения совместного доступа к общему коду. Решим её организационными путями? Разобьём код на модули и сделаем git hook, который запрещает пушить в чужие модули или хотя бы оповещает владельца? Сделаем нормальное code review?
Нет, давайте лучше потратим человеко-годы и кучу железа (т.к. у нас теперь всё взамодействует по сети) на переписывание всего на микросервисы. А потом ещё столько же на поддержку получившегося поделия.
Тут по-моему очевидно, что если у вас был плохой и корявый монолит, то получатся такие же микросервисы, вопрос исключительно инженерной культуры в компании.
Ну и совершенно верно выше писали — по факту, миллениалы изобрели модульность :)
Единственный конструктивный посыл от микросервисов — это раздельное масштабирование, но возникает такая проблема только на правда большом масштабе (как минимум, сотни и тысячи физических серверов, но и тут как правило хватает SOA).
А истории «у нас CRM система на заводе, мы всё переписываем на микросервисы» — это классический пример, когда не очень толкового менеджера надурили не очень толковые программисты, которым скучно писать бизнес-логику, а амбициозных задач не предвидится — вот они их сами и придумывают за счет работодателя :)
Первое, что приходит в голову — github.com/alexeyrybak/blitz/wiki
Хотя я не большой эксперт по шаблонизаторам в php и почти уверен, что по сравнению с участниками вашего теста, у блица весьма скудный функционал.
Но посмотреть на бенчмарк было бы интересно :)
Конечно, очень умиляет, как вы нарочито называете Badoo галерой :)
Там такая «галера», где специальный мужик по утрам завтраки готовит как в турецком отеле, с массажем, кучей еды и перков. Погуглите ради интереса фотки офиса :)
Да и уровень зарплат (по тому же Glassdoor-у) не особо выглядит заниженным, если честно.
Простите, я вот вообще не эксперт по жизни в UK, но немного не пойму.
Разве, например, в РФ ситуация не такая же?
В гос клинике не то что некачественное лечение — туда даже заходить страшно, в страховых +- норм, но надо постараться чтобы найти адекватных и грамотных врачей даже в огромной Москве.
Думаю, в UK ситуация слабо отличается, хотя, судя по отзывам гос врачи «на троечку» и не особо горят желанием вас комплексно диагностировать чуть что. В то время как такие же в РФ это беда и кошмар.
Есть ощущение, что бесплатная гос медицина по стандартам коммерческой это почти утопия и переживать по этому поводу смысла нет.
Спасибо за ответ. Согласен, такая балансировка это по факту отсутствие балансировки (регулируется только живость хостов, не нагрузка), т.к. каждый клиент сам делает свой round-robin, а не один сквозной на всех :) в случае со стримами так вообще беда. Или если клиентов много, то еще и гигантское количество TCP соединений на каждом gRPC сервере. Статья выглядит годной
Спасибо за статью, очень круто. Немного оффтоп, но не могли бы подробнее рассказать про балансировку gRPC? Она происходит на gRPC клиенте (в статье вроде было про service discovery)? Или все же есть промежуточный http2 балансировщик? Если да, то какой?
я не фанат Яндекса от слова совсем, но в этом месте надо отдать им должное. все проблемы, которые у меня возникали при интенсивном использовании (пользовался почти каждый день в течении пары месяцев), они решали хорошо и быстро через чат с поддержкой в приложении
Единственное, в чем будет разница по памяти между запущенным инстансом монолита и микросервиса, которые делают одно и то же — это в размере бинарника. Именно на эту разницу и увеличится потребление памяти. Память стоит копейки. Ради того, чтобы ее сэкономить вы чудовищно усложняете разработку и поддержку, вводите кучу сущностей, процессов и инструментов, а это как раз стоит дорого.
Как вам вообще удаётся бизнесу продавать такие вещи?
Вместо find usages и проверки всех использований вам надо каким-то образом при любом изменении бегать по графу зависимостей всех ваших сервисов, причём рекурсивно.
Так. Стоп. То есть юнит тесты на пакет/класс в коде вас не устраивают, а вот если вынести это в отдельное приложение и сделать такие же тесты, то все магически меняется?
Великолепная логика
Два чая этому господину. Вот так взяли и структурированно и понятно описали именно то, что мне каждый раз приходит в голову, когда слышу очередные истории успеха от адептов микросервисов. Единственный вменяемый аргумент это возможность проще скейлится и делать это динамически + нет привязки к одному стеку company wide. Но это плюсы, которые действительно полезны на большом масштабе, а не в проекте уровня CRM система на заводе
в случае с кафкой можно просто взять один топик (с фиксированным количеством партишенов) и в качестве ключа для партицирования использовать user_id.
каждый partition разгребать в один поток.
все задания этого юзера гарантированно будут там и обработаются последовательно.
думаю, что в 99% процентов случаев никаких проблем с перфомансом не будет.
либо как альтернатива — брать абсолютно любой брокер, в нем одну очередь, разбирать в любое количество потоков, а перед обработкой записи пробовать брать лок в каком-то стороннем месте (mysql SELECT GET_LOCK в базе где хранится юзер или в zookeper/consul). Конкретный юзер сейчас залочен? Сделали этому эвенту postpone и попробовали чуть позже (вопрос реализации postpone зависит уже от брокера)
Простите за прямоту, но ваши ответы показывают что вы либо фантазер-максималист, совершенно оторванный от реалий индустрии, либо у вас какой-то уж очень специфический опыт.
Компании дерутся за адекватных обучаемых людей, прекрасно понимая что конкретный фреймворк или технология совершенно вторичны и легко осваиваются (плюс в крупных как правило все равно все свое), и грамотно инвестированные в человека пара недель-месяц на старте потом с лихвой окупятся.
А с вашей позицией я смутно представляю себе как можно кого-то вменяемого нанять.
представьте, что у вас есть self hosted git репозиторий внутри компании.
не github, не bitbucket, которые действительно предоставляют функционал для pull request-ов из коробки, а просто git репозиторий.
основная сложность тут не в том, чтобы доставить ваш diff в систему контроля версий, а в том, чтобы организовать всю обвязку вокруг.
помимо diff-а, вам нужно через какой-то ui:
— выбрать ревьюера
— выбрать тикет к которому прилинковать hotfix
— автоматом прогнать unit и smoke тесты
— дождаться пока ревьюер нажмет approve
— дождаться, пока разработчик нажмет кнопку «все готово, поехали на продакшен»
(делать это сразу после approve не очень хорошая идея)
— выложить hotfix на продакшен и замержить в мастер
конкретный способ доставки diff-а в эту систему тут вообще не играет никакой роли, самое важное и сложное — это как раз все последующие шаги.
и раз уж вы все равно делаете веб-интерфейс для их реализации, логичным выглядит добавление туда поля diff, чтобы не придумывать сложный механизм автоматического обнаружения этих hotfix-веток.
если говорить о детялах, то положить git diff в clipboard отличается от git format-patch по сути только оформлением, суть абсолютно одна и та же.
Не обижайтесь, но вам абсолютно верно указали.
Описанный подход лично я считаю вредительским и явным оверинжинирингом.
Вместо того чтобы сделать нормальные абстракции поверх интерфейсов, а ещё лучше вообще их не делать, пока не возникло ВНЕЗАПНО НЕОБХОДИМОСТИ поменять реализацию коннекта к базе или ещё чего-то такого (как по мне, это все равно невозможно сделать таким способом irl)
Посыл то правильный — надо писать нормальный тестируемый код с нормальными абстракциями и разделением ответственности, но реализация просто чудовищная
С точки зрения логики все должно быть так, но я как раз вокруг себя вижу противоположную картину. Люди, которые раньше не особенно вовлекались в работу, с невысоким уровнем личной ответственности (как правило <L5) и без «огня в душе» часто очень громко говорят, как им нравится удалёнка, какой у них жизненный баланс наладился, а волосы стали гладкими и шелковистыми.
А вот условные синьоры, лиды и выше поголовно вешаются от удалёнки и считают дни до возвращения в офис, т.к. поддерживать высокий уровень вовлечения и продуктивно взаимодействовать в команде стало на порядок тяжелее.
Понятно, что оба подхода имеют право на существование и никто не обязан быть фанатиком на работе, но все же рассказы про продуктивность частично звучат как самообман.
Просто у тех, кто раньше не вовлекался в работу теперь есть возможность поддерживать лучший баланс (особенно на фоне того, что руководителям/старшим товарищам вовлекать их стало сложнее). Ну и, само собой, должен быть процент супер-дисциплинированных людей с особым mindset-ом, на кого это правда позитивно повлияло (даже в долгую), но кажется что таких людей в целом немного.
У нас есть сугубо организационная проблема ограничения совместного доступа к общему коду. Решим её организационными путями? Разобьём код на модули и сделаем git hook, который запрещает пушить в чужие модули или хотя бы оповещает владельца? Сделаем нормальное code review?
Нет, давайте лучше потратим человеко-годы и кучу железа (т.к. у нас теперь всё взамодействует по сети) на переписывание всего на микросервисы. А потом ещё столько же на поддержку получившегося поделия.
Тут по-моему очевидно, что если у вас был плохой и корявый монолит, то получатся такие же микросервисы, вопрос исключительно инженерной культуры в компании.
Ну и совершенно верно выше писали — по факту, миллениалы изобрели модульность :)
Единственный конструктивный посыл от микросервисов — это раздельное масштабирование, но возникает такая проблема только на правда большом масштабе (как минимум, сотни и тысячи физических серверов, но и тут как правило хватает SOA).
А истории «у нас CRM система на заводе, мы всё переписываем на микросервисы» — это классический пример, когда не очень толкового менеджера надурили не очень толковые программисты, которым скучно писать бизнес-логику, а амбициозных задач не предвидится — вот они их сами и придумывают за счет работодателя :)
Он просто настолько стабилен и хорош, что все идеально работает и больше ничего добавлять не нужно!
Хотя я не большой эксперт по шаблонизаторам в php и почти уверен, что по сравнению с участниками вашего теста, у блица весьма скудный функционал.
Но посмотреть на бенчмарк было бы интересно :)
Там такая «галера», где специальный мужик по утрам завтраки готовит как в турецком отеле, с массажем, кучей еды и перков. Погуглите ради интереса фотки офиса :)
Да и уровень зарплат (по тому же Glassdoor-у) не особо выглядит заниженным, если честно.
Разве, например, в РФ ситуация не такая же?
В гос клинике не то что некачественное лечение — туда даже заходить страшно, в страховых +- норм, но надо постараться чтобы найти адекватных и грамотных врачей даже в огромной Москве.
Думаю, в UK ситуация слабо отличается, хотя, судя по отзывам гос врачи «на троечку» и не особо горят желанием вас комплексно диагностировать чуть что. В то время как такие же в РФ это беда и кошмар.
Есть ощущение, что бесплатная гос медицина по стандартам коммерческой это почти утопия и переживать по этому поводу смысла нет.
Спасибо за статью, очень круто. Немного оффтоп, но не могли бы подробнее рассказать про балансировку gRPC? Она происходит на gRPC клиенте (в статье вроде было про service discovery)? Или все же есть промежуточный http2 балансировщик? Если да, то какой?
Единственное, в чем будет разница по памяти между запущенным инстансом монолита и микросервиса, которые делают одно и то же — это в размере бинарника. Именно на эту разницу и увеличится потребление памяти. Память стоит копейки. Ради того, чтобы ее сэкономить вы чудовищно усложняете разработку и поддержку, вводите кучу сущностей, процессов и инструментов, а это как раз стоит дорого.
Как вам вообще удаётся бизнесу продавать такие вещи?
Полностью согласен. Это вопрос масштаба исключительно
Вместо find usages и проверки всех использований вам надо каким-то образом при любом изменении бегать по графу зависимостей всех ваших сервисов, причём рекурсивно.
Так. Стоп. То есть юнит тесты на пакет/класс в коде вас не устраивают, а вот если вынести это в отдельное приложение и сделать такие же тесты, то все магически меняется?
Великолепная логика
Два чая этому господину. Вот так взяли и структурированно и понятно описали именно то, что мне каждый раз приходит в голову, когда слышу очередные истории успеха от адептов микросервисов. Единственный вменяемый аргумент это возможность проще скейлится и делать это динамически + нет привязки к одному стеку company wide. Но это плюсы, которые действительно полезны на большом масштабе, а не в проекте уровня CRM система на заводе
в случае с кафкой можно просто взять один топик (с фиксированным количеством партишенов) и в качестве ключа для партицирования использовать user_id.
каждый partition разгребать в один поток.
все задания этого юзера гарантированно будут там и обработаются последовательно.
думаю, что в 99% процентов случаев никаких проблем с перфомансом не будет.
либо как альтернатива — брать абсолютно любой брокер, в нем одну очередь, разбирать в любое количество потоков, а перед обработкой записи пробовать брать лок в каком-то стороннем месте (mysql SELECT GET_LOCK в базе где хранится юзер или в zookeper/consul). Конкретный юзер сейчас залочен? Сделали этому эвенту postpone и попробовали чуть позже (вопрос реализации postpone зависит уже от брокера)
Компании дерутся за адекватных обучаемых людей, прекрасно понимая что конкретный фреймворк или технология совершенно вторичны и легко осваиваются (плюс в крупных как правило все равно все свое), и грамотно инвестированные в человека пара недель-месяц на старте потом с лихвой окупятся.
А с вашей позицией я смутно представляю себе как можно кого-то вменяемого нанять.
не github, не bitbucket, которые действительно предоставляют функционал для pull request-ов из коробки, а просто git репозиторий.
основная сложность тут не в том, чтобы доставить ваш diff в систему контроля версий, а в том, чтобы организовать всю обвязку вокруг.
помимо diff-а, вам нужно через какой-то ui:
— выбрать ревьюера
— выбрать тикет к которому прилинковать hotfix
— автоматом прогнать unit и smoke тесты
— дождаться пока ревьюер нажмет approve
— дождаться, пока разработчик нажмет кнопку «все готово, поехали на продакшен»
(делать это сразу после approve не очень хорошая идея)
— выложить hotfix на продакшен и замержить в мастер
конкретный способ доставки diff-а в эту систему тут вообще не играет никакой роли, самое важное и сложное — это как раз все последующие шаги.
и раз уж вы все равно делаете веб-интерфейс для их реализации, логичным выглядит добавление туда поля diff, чтобы не придумывать сложный механизм автоматического обнаружения этих hotfix-веток.
если говорить о детялах, то положить git diff в clipboard отличается от git format-patch по сути только оформлением, суть абсолютно одна и та же.
Начали про безумный страшный DI, а теперь уже скатились к дженерикам :-)
Описанный подход лично я считаю вредительским и явным оверинжинирингом.
Вместо того чтобы сделать нормальные абстракции поверх интерфейсов, а ещё лучше вообще их не делать, пока не возникло ВНЕЗАПНО НЕОБХОДИМОСТИ поменять реализацию коннекта к базе или ещё чего-то такого (как по мне, это все равно невозможно сделать таким способом irl)
Посыл то правильный — надо писать нормальный тестируемый код с нормальными абстракциями и разделением ответственности, но реализация просто чудовищная