Что такого особенного в проекте, чтобы в относительно небольшом интернет-магазине запросы по 20 секунд работали? Да даже по 2?
Пока из тех кейсов с graphql, что видел, оправданным выглядит только один — объединение нескольких разрозненных api за единым фасадом. В остальных случаях, если поспрашивать, аргументов кроме "модно, молодежно" особо и не было
Я пытаюсь сказать, что чтобы создать самоорганизованную команду с высоким уровнем доверия как внутри нее, так и извне к ней самой, методологий мало. Собственно, методологии и не описывают как это делать.
Проблемы в как таковом Scrum'е нет. Хотя, сейчас все больше и больше аргументированно агитируют за Канбан, как фреймворк, который максимально сокращает релизный цикл.
Проблема в том, что этот Скрам преподносится, как серебряная пуля. Как будто внедрив Скрам внезапно команды преобразятся и начнут деливерить.
И многие менеджеры этому верят. И потом приходит к команде такой менеджер, который нифига не умеет, не знает, с командой контакта найти не может, и, несмотря на наличие daily, не понимает чем команда реально занята и говорит, что Скрам нас всех спасет.
Мне повезло (и это реально везение) иметь опыт работы с реально эффективными PM'ами, которые и наберут группу людей, и сделают эту группу командой, и будут с заказчиком эффективно коммуницировать, и команду слушать. И, что характерно, Скрам им не нужен. Просто потому, что ритуалы Скрама — лишь малая часть их работы.
Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды.
Не согласен. Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет. Проблема в том, что одного его недостаточно.
Если кто-то игнорирует — сыпется все
А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?
Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно
Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама. Ну и про то, что «строгое следование инструкциям» называется «итальянской забастовкой» я вообще молчу.
Управление проектами и командами — сложная работа, которой равно также надо учиться, как и, например, разработке. Скрам — всего лишь одна из методологий и даже совершенное владение ею не делает менеджера хорошим управленцем. Вот и все. К сожалению, сейчас скрам все еще преподносится как серебряная пуля, но уже есть подвижки к понимаю, что это не так.
Проблема в том, что к тем разрабам, "кто будет" могут придти заказчики, подверженные хайпу. Которые думают, что какая-то архитектура автоматом решит все их проблемы, хотя все их аргументы, если капнуть, сводятся к тому, что все вокруг просто об этом говорят.
А потом появляются архитекторы, которые, смотря на тренды, начинают пихать какой-то подход во все проекты подряд.
Простите, а каким образом при переходе к nio потребление памяти в 5 раз сократилось? Можно конкретику — на каких именно объектах?
В остальном же, да, у монолитов есть свои минусы. Но это также не означает, что микросервисы автоматом решают все проблемы и что с ними будет сильно лучше. Серебрянной пули нет.
В общем-то, я за МАКРОсервисы/soa или как там оно называется. Пихать все в один процесс, действительно, очень часто неразумно. Но большинству проектов очень долгое время будет прекрасно на модульном монолите житься.
Вы, наверное, говорите о той ситуации, где микросервисов владеет выделенная команда? Где независимая разработка и деплой? Где зависимости и зависимые четко известны и предсказуемы?
Потому что если нет, то объяснять надо не только сам микросервис, а еще кучу всего, начиная с предметной области. И чтобы понять как работают некие комплексные бизнес сценарии в микросервисах в какой-нибудь банковской сфере, надо упороться. С монолитом тоже надо будет упарываться, но там IDE еще сильно поможет.
А если же ответ — «да», то я вас огорчу — таких проектов очень мало.
Я прекрасно знаю о тотальной декомпозиции. Был такой опыт и неоднократно. И опыт это был крайне негативный. Начиная от постоянных срачей какие технологии и как использовать, чтобы «свобода выбора технологий» не превратилась в «неподдерживаемый хаос» и кончая тем, что такие вещи, как «независимая разработка» и «независимые релизы» становились просто невозможными. Я уж молчу, что набирать разрабов под разные стеки технологий (Java, Python, бинари и т.п.) — тот еще геморрой.
Еще раз: можно ли построить хорошую микросервисную архитектуру, чтобы проект от этого выиграл? Да, конечно. Подходят ли микросервисы большинству проектов — нет.
Вы говорите про те проекты, где микросервисы спроектированы хорошо. Так скажем, «по стандарту». Лично я таких проектов не видел. В реальности у меня жизнь всегда вносила коррективы, и микросервисы раз за разом предлагались в проекты не по правильному балансу плюсов и минусов, а из-за хайпа.
Что мешает тестировать монолит теми же подходами, что и микросервисы, — для меня загадка. Если это не жуткое легаси, то я от монолита ровно также ожидаю модульного подхода с нормальной пирамидой тестирования.
Новую версию библиотеки — легко, если есть хорошее покрытие.
Другую парадигму — да, очень тяжело. Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется. Есть много не самых очевидных проблем, которые так или иначе всплывут:
Обучение разработчиков
Грань между свободой выбора технологии и хаосом очень тонка и будет потрачено крайне много времени на ее очерчивание
Асинхронный код, если же мы заговорили о нем, часто требует и других настроек auto scaling'а
Выплывает куча разных болячек, если использовать не проверенный временем стек технологий
Казалось бы, не так и страшно, но в реальном проекте, при минимальном наличии бюрократии/замороченных архитекторах, будет плохо. Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
CI/CD — это не только Jenkins (или альтернативу) поставить. Это и подходы к тестированию, и правильная реализация этих тестов. К примеру, в случае микросервисов без контрактного тестирования проблемы интеграции будут всплывать постоянно. End-to-end тестов необходимо будет больше, а их делать сложнее.
Кроме тестов, есть еще куча других процедур и проверок: всякие проверки на обратную совместимость API, создание документации, настройки zipkin/jaegor'ов, настройки сетевого стека и т.п. и т.д.
Кроме того, в нормальных ситуациях у микросервисов свои хранилища данных. Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.
Ну и последнее — про scaling. Все так часто его приводят, но почему мало кто вспоминает, что на большинстве проектов большинство сервисов зависят от неких хранилищ данных. И масштабирование зачастую упирается в эти хранилища, а не в инстансы stateless сервисов.
Все-таки, я позволю себе вас поправить: в микросервисах намного больше плюсов в тех проектах, для которых микросервисы подходят. А таких проектов — абсолютное меньшинство из-за того, что микросервисы помимо плюсов привносят и много минусов и на большинстве проектов минусы будут перевешивать.
Это все делается прекрасно и в монолите — просто поделите на модули. А чтобы джунам было неповадно нарушать границы, есть code review и всякие автоматизированные тула аля JArchitect / ArchUnit (для Java). Если же нет нормального code review и статического анализа, то и микросервисы выйдут такими, что поддерживать это будет нереально.
Кроме того, в реальности же часто получается так, что в погоне за «четкими границами модулей», эти границы очерчиваются так, что о независимых релизах люди вспоминают только в мечтах.
Можно говорить о том, что должны существовать умные дядьки, правильно ограничивающие границы и т.п. Но в Java это уже все проходили, причем неоднократно — куча идей, проектов, стандартов и мечтаний о том, что архитекторы нарисуют диаграммы классов, а джуны закодят. И все это выливается все равно в монструозные и неподдерживаемые системы.
Безусловно, существуют проекты, где микросервисы будут во благо, но таких проектов очень мало. Намного меньше, чем большинству кажется.
Я, как тим-лид, примерно считал оверхед по времени разработки в микросервисной архитектуре. Он был от 30%. Это время только разработчиков. Про дополнительные затраты на инфраструкту и CI/CD вообще молчу. Также, появляется больше багов, т.к. распределенная система сложнее и делается больше ошибок, усложняется отладка и очень сильно усложняется тестирование.
Так что для себя вывод сделал однозначный — если в команде человек 10, максимум, разрабов, то о микросервисах даже и говорить не надо.
Я не видел еще ни одного проекта, где микросервисы уменьшают сложность. Обычно, как раз, бывает ровно наоборот, т.к. распределенные системы априори более сложные. Кроме того, обычно если команда не может писать нормальный код в монолите, то и в микросервисах выйдет не лучше.
Микросервисы — ни разу не панацея и в большинстве случаев приведет только к замедлению разработки и усложнению поддержки.
Да, для анализа pull-реквестов, например. Без типизации переменной понимать что хотел сказать автор кода — более затруднительно.
С моей т.з. это не так. Код с val/var (а они и в Lombok для Java есть) более лаконичный и reviewer тупо меньше читать должен. Становится меньше визуального мусора, поэтому и проще вычленить логику.
Когда мне нужен лев, а не утка — мне пофигу как кого зовут.
А можно конкретнее?
Чойта вдруг? Bean-методы тоже поди харамны? А конфиг с такими методами? А это уже фабрика.
Тем не менее, это и близко не то, что вы описали в примере выше. Кроме того, я видел немало проектов, где, несмотря на наличие Spring, все равно накручивали собственные, отдельные фабрики. Поддерживать это крайне тяжело.
Да, я сам N-ое кол-во лет назад говорил «зачем нужны лямбды в Java, есть же анонимные классы — сразу видны все типы, а пишутся они в IDE быстро».
Нечитабильно можно написать на любом языке. Поверьте, я и на Java уже на много говнокода насмотрелся.
Но основная проблема — когда бизнес логика нечитаема. А это — уже не о синтаксисе, а о выбранных абстракциях, ответственностях и наименованиях.
Касаемо val/var. Еще раз: человек — не компилятор. Если вам необходимы типы локальных переменных, то лучше подумать над следующими вопросами:
Зачем мне это? Не пытаюсь ли я делать ту работу, которую должен делать компилятор или статический анализатор?
Например, для редактирования кода человек использует IDE. Блокнот/web используется для его чтения.
Достаточно ли мои методы просты? Может, тут надо не типы указывать, а часть логики по приватным методам разбить? Также, привет всяким SOLID, YAGNI.
Корректные ли имена используются? Суть должны быть понятна из имен, а не типов.
Касаемо вашего примера о фабрике. Во-первых, возвращаемые абстрактные классы все равно все будут из одной иерархии. Во-вторых, паттерн фабрика сейчас, в мире Spring и альтернатив, используется настолько редко, что уже его наличие в коде должно говорить о том, что, возможно, абстракции выбраны неверно.
Ровно по этим же аргументам лучше использовать static import. Там, где имена импортируемых элементов говорящие, конечно (isEmpty(...) импортируем, builer() — нет).
А потом мне, как лиду, приходится объяснять разрабам, что код пишется для людей и что люди не должны на ревью заменять компилятор. И что если вам непонятно что находится в переменной без указания типа, то это — сигнал к рефакторингу, а не к тому, чтобы тип указывать.
Что такого особенного в проекте, чтобы в относительно небольшом интернет-магазине запросы по 20 секунд работали? Да даже по 2?
Пока из тех кейсов с graphql, что видел, оправданным выглядит только один — объединение нескольких разрозненных api за единым фасадом. В остальных случаях, если поспрашивать, аргументов кроме "модно, молодежно" особо и не было
Проблемы в как таковом Scrum'е нет. Хотя, сейчас все больше и больше аргументированно агитируют за Канбан, как фреймворк, который максимально сокращает релизный цикл.
Проблема в том, что этот Скрам преподносится, как серебряная пуля. Как будто внедрив Скрам внезапно команды преобразятся и начнут деливерить.
И многие менеджеры этому верят. И потом приходит к команде такой менеджер, который нифига не умеет, не знает, с командой контакта найти не может, и, несмотря на наличие daily, не понимает чем команда реально занята и говорит, что Скрам нас всех спасет.
Мне повезло (и это реально везение) иметь опыт работы с реально эффективными PM'ами, которые и наберут группу людей, и сделают эту группу командой, и будут с заказчиком эффективно коммуницировать, и команду слушать. И, что характерно, Скрам им не нужен. Просто потому, что ритуалы Скрама — лишь малая часть их работы.
Не согласен. Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет. Проблема в том, что одного его недостаточно.
А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?
Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама. Ну и про то, что «строгое следование инструкциям» называется «итальянской забастовкой» я вообще молчу.
Управление проектами и командами — сложная работа, которой равно также надо учиться, как и, например, разработке. Скрам — всего лишь одна из методологий и даже совершенное владение ею не делает менеджера хорошим управленцем. Вот и все. К сожалению, сейчас скрам все еще преподносится как серебряная пуля, но уже есть подвижки к понимаю, что это не так.
Проблема в том, что к тем разрабам, "кто будет" могут придти заказчики, подверженные хайпу. Которые думают, что какая-то архитектура автоматом решит все их проблемы, хотя все их аргументы, если капнуть, сводятся к тому, что все вокруг просто об этом говорят.
А потом появляются архитекторы, которые, смотря на тренды, начинают пихать какой-то подход во все проекты подряд.
Простите, а каким образом при переходе к nio потребление памяти в 5 раз сократилось? Можно конкретику — на каких именно объектах?
В остальном же, да, у монолитов есть свои минусы. Но это также не означает, что микросервисы автоматом решают все проблемы и что с ними будет сильно лучше. Серебрянной пули нет.
В общем-то, я за МАКРОсервисы/soa или как там оно называется. Пихать все в один процесс, действительно, очень часто неразумно. Но большинству проектов очень долгое время будет прекрасно на модульном монолите житься.
Потому что если нет, то объяснять надо не только сам микросервис, а еще кучу всего, начиная с предметной области. И чтобы понять как работают некие комплексные бизнес сценарии в микросервисах в какой-нибудь банковской сфере, надо упороться. С монолитом тоже надо будет упарываться, но там IDE еще сильно поможет.
А если же ответ — «да», то я вас огорчу — таких проектов очень мало.
Я прекрасно знаю о тотальной декомпозиции. Был такой опыт и неоднократно. И опыт это был крайне негативный. Начиная от постоянных срачей какие технологии и как использовать, чтобы «свобода выбора технологий» не превратилась в «неподдерживаемый хаос» и кончая тем, что такие вещи, как «независимая разработка» и «независимые релизы» становились просто невозможными. Я уж молчу, что набирать разрабов под разные стеки технологий (Java, Python, бинари и т.п.) — тот еще геморрой.
Еще раз: можно ли построить хорошую микросервисную архитектуру, чтобы проект от этого выиграл? Да, конечно. Подходят ли микросервисы большинству проектов — нет.
Что мешает тестировать монолит теми же подходами, что и микросервисы, — для меня загадка. Если это не жуткое легаси, то я от монолита ровно также ожидаю модульного подхода с нормальной пирамидой тестирования.
Другую парадигму — да, очень тяжело. Но проблема в том, что и другую парадигму и на микросервисах впихнуть не так просто, как кажется. Есть много не самых очевидных проблем, которые так или иначе всплывут:
Казалось бы, не так и страшно, но в реальном проекте, при минимальном наличии бюрократии/замороченных архитекторах, будет плохо. Большинству бизнесов надо фичи деливерить, а не хотелки разрабов удовлетворять.
CI/CD — это не только Jenkins (или альтернативу) поставить. Это и подходы к тестированию, и правильная реализация этих тестов. К примеру, в случае микросервисов без контрактного тестирования проблемы интеграции будут всплывать постоянно. End-to-end тестов необходимо будет больше, а их делать сложнее.
Кроме тестов, есть еще куча других процедур и проверок: всякие проверки на обратную совместимость API, создание документации, настройки zipkin/jaegor'ов, настройки сетевого стека и т.п. и т.д.
Кроме того, в нормальных ситуациях у микросервисов свои хранилища данных. Их тоже надо обслуживать, мигрировать, реплицировать и т.д. Затраты на это огромны.
Ну и последнее — про scaling. Все так часто его приводят, но почему мало кто вспоминает, что на большинстве проектов большинство сервисов зависят от неких хранилищ данных. И масштабирование зачастую упирается в эти хранилища, а не в инстансы stateless сервисов.
Кроме того, в реальности же часто получается так, что в погоне за «четкими границами модулей», эти границы очерчиваются так, что о независимых релизах люди вспоминают только в мечтах.
Можно говорить о том, что должны существовать умные дядьки, правильно ограничивающие границы и т.п. Но в Java это уже все проходили, причем неоднократно — куча идей, проектов, стандартов и мечтаний о том, что архитекторы нарисуют диаграммы классов, а джуны закодят. И все это выливается все равно в монструозные и неподдерживаемые системы.
Безусловно, существуют проекты, где микросервисы будут во благо, но таких проектов очень мало. Намного меньше, чем большинству кажется.
Так что для себя вывод сделал однозначный — если в команде человек 10, максимум, разрабов, то о микросервисах даже и говорить не надо.
Я не видел еще ни одного проекта, где микросервисы уменьшают сложность. Обычно, как раз, бывает ровно наоборот, т.к. распределенные системы априори более сложные. Кроме того, обычно если команда не может писать нормальный код в монолите, то и в микросервисах выйдет не лучше.
Микросервисы — ни разу не панацея и в большинстве случаев приведет только к замедлению разработки и усложнению поддержки.
Под примерами я имел ввиду пример, что где помогает.
С моей т.з. это не так. Код с val/var (а они и в Lombok для Java есть) более лаконичный и reviewer тупо меньше читать должен. Становится меньше визуального мусора, поэтому и проще вычленить логику.
А можно конкретнее?
Тем не менее, это и близко не то, что вы описали в примере выше. Кроме того, я видел немало проектов, где, несмотря на наличие Spring, все равно накручивали собственные, отдельные фабрики. Поддерживать это крайне тяжело.
Да, я сам N-ое кол-во лет назад говорил «зачем нужны лямбды в Java, есть же анонимные классы — сразу видны все типы, а пишутся они в IDE быстро».
Нечитабильно можно написать на любом языке. Поверьте, я и на Java уже на много говнокода насмотрелся.
Но основная проблема — когда бизнес логика нечитаема. А это — уже не о синтаксисе, а о выбранных абстракциях, ответственностях и наименованиях.
Касаемо val/var. Еще раз: человек — не компилятор. Если вам необходимы типы локальных переменных, то лучше подумать над следующими вопросами:
Например, для редактирования кода человек использует IDE. Блокнот/web используется для его чтения.
Касаемо вашего примера о фабрике. Во-первых, возвращаемые абстрактные классы все равно все будут из одной иерархии. Во-вторых, паттерн фабрика сейчас, в мире Spring и альтернатив, используется настолько редко, что уже его наличие в коде должно говорить о том, что, возможно, абстракции выбраны неверно.
Ровно по этим же аргументам лучше использовать static import. Там, где имена импортируемых элементов говорящие, конечно (isEmpty(...) импортируем, builer() — нет).
А потом мне, как лиду, приходится объяснять разрабам, что код пишется для людей и что люди не должны на ревью заменять компилятор. И что если вам непонятно что находится в переменной без указания типа, то это — сигнал к рефакторингу, а не к тому, чтобы тип указывать.