Но если надо в 10+ раз повысить нагрузку, то эти методы могут не справиться
Да, я не отрицаю, что в каких-то случаях МС могут быть правильным решением. Просто это крайне редкие случаи – мне, например, пока сталкиваться не приходилось.
Не бывает таких монолитов, которые из за одного исключения в одной функции ломались бы полностью.
Да. Тоже собирался об этом написать, но пропустил. Точнее, у меня, например, есть некое общее ядро, неудачные изменения в котором теоретически могут вообще всё положить. Но такие вещи невозможно не заметить при тестировании, да и с микросервисами в этом случае произойдёт ровно то же самое. Если, разумеется, каждая МС команда не пишет его весь от начала до конца сама, изолированно – что свидетельствовало бы о крайне нерациональном использовании ресурсов.
Что мне мешает добавить нужное количество нод на монолите? В том числе, динамически, по необходимости. Всё, что требуется – это поставить перед ними балансировщик нагрузки – который в высоконагруженных системах и так всегда уже есть.
❌ Сложнее обновлять и поддерживать. Любые изменения в монолитной архитектуре нужно вносить во все приложение сразу. Это может приводить к заторам в разработке — если одна команда не готова к релизу, все должны ждать, пока она закончит.
Допустим, у меня есть команда, которая реализует обработку платежей, и ещё одна, которая занимается рассылкой мэйлов. Почему они должны ждать друг друга? Абсолютно несвязанный код, который можно релизить независимо. Если речь о бэке и фронте – так для того и придумали версионирование API, обратную совместимость и прочие техники, облегчающие независимую разработку модулей системы. Просто это должно быть продумано ещё на этапе проектирования.
✅Гибкость разработки. Элементы приложения можно разрабатывать, тестировать и деплоить независимо друг от друга. Команды могут использовать разные технологии и подходы для каждого сервиса и не конфликтовать друг с другом.
Зоопарк технологий в одном проекте - скорее минус, нежели плюс.
____
А вот с перечисленными минусами микросервисов согласен абсолютно. И они настолько серьёзны, что переход на МС архитектуру должен быть очень хорошо обоснован, чтобы вообще в эту историю ввязываться.
А читая о том, что
В реальности же таких микросервисов будет сотни, а то и тысячи.
никак не удаётся избавиться от ощущения, что система попросту плохо спроектирована. О чём тут речь, о типах сервисов или об инстансах? Второй случай ещё как-то можно понять – хотя боюсь, накладные расходы на запуск такого количества процессов и управление ими сами по себе съедят до фига ресурсов, и потребуют того самого горизонтального масштабирования гораздо раньше, чем в случае с монолитом. Тысячи типов объяснить не могу никак, не бывает систем такой сложности – если не лепить по 4 сервиса на каждую CRUD сущность.
Итого: думаю, что повальное увлечение микросервисами вряд ли обосновано. Есть случаи, когда они нужны – но это действительно очень большие, многофункциональные и высоконагруженные системы. Для абсолютного же большинства это ведет лишь к огромному усложнению инфраструктуры, сложность реализации которой и поддержания её в рабочем состоянии может значительно превышать выигрыш в сравнении с хорошо спроектированным монолитом.
Готов к приёму пинков от церкви свидетелей микросервисной архитектуры 😁
отсутствие софта на смартфоне, который бы подыскивал и подсказывал мне интересные достопримечательности по ходу движения (неважно пешком или на машине). Желательно голосом.
Ну почему сразу "отсутствие". Никогда не пробовал включать, ибо обычно моя задача – добраться до нужного пункта в незнакомом городе, и в таком случае отвлекаться на достопримечательности не очень получается, но вроде это оно и есть:
А если не голосом, то отображение POI на карте практически в любом навигаторе есть.
Можно плюсовать комментарии всех оппонентов противника
Трудно сказать. Отсутствие плюсов – тоже минус. Я, собственно, в основном о том, что в реальности минусы ставятся больше на эмоциях, нежели основываясь на содержании. Об этом и в статье написано – думаю, что оценке автора, имеющего доступ к аналитическим материалам ресурса, вполне можно верить. А если так, то они теряют изначальный смысл: борьбу с некачественным материалом силами сообщества.
А оно действительно важно? Честно говоря, отсутствие возможности ставить минусы не угнетает вообще. Более того, не уверен, что такая фича в принципе нужна. Минус (с моей точки зрения) заслуживает неприкрытое хамство или совсем уж неадекватный текст – и то, и другое на хабре встречается крайне редко. И с такими эксцессами скорее помогла бы бороться кнопка "послать модератору", а не минусы.
Программирование - это ремесло, доступное каждому, кто готов приложить усилия и развивать свои навыки.
Не то, чтобы это было неверно, но на мой взгляд, не отражает некоторых важных нюансов. Дело в том, что это вот "готов приложить и развивать" – отнюдь не разовое состояние, а по сути непрерывное, от начала и до самого конца карьеры. Иначе в лучшем случае получится плохой программист, в худшем – никакого. "Закончу курсы, научусь и буду много зарабатывать" тут не прокатывает – практически обязательной является какая-никакая склонность именно к этому виду деятельности, желание погружаться в тему глубже и глубже – причём процесс этот должен доставлять удовольствие. Иначе через некоторое время неизбежно начнутся модные охи и ахи про "выгорание", "галеры" и прочую ахинею – которые на самом деле свидетельствуют лишь о том, что человек занимается не свойственным ему делом, за которое взялся либо в силу моды, либо под давлением родителей, либо в надежде начать много зарабатывать при умеренных усилиях.
код который легко покрыть тестами скорее всего не эффективный )
Эффективность – штука тонкая. Она не должна быть максимально возможной – скорее достаточной. И честно говоря, в большинстве проектов вопрос эффективности не стоит вообще. Даже там, где она на самом деле важна, часто дешевле купить железо помощнее, чем оплачивать команду супер специалистов, умеющих в Hi Load. Как говаривал один заказчик: вам нужно ещё 100 гиг памяти? Я вам её куплю, но дайте мне результат к концу недели. Да и тестируемость тоже – круто иметь 100% покрытие, конечно, но чаще всего это просто избыточно.
Озвучьте пожалуйста критерии понятного, поддерживаемого и эффективного кода.
Я бы предложил парочку в части понятности и поддерживаемости, вроде достаточно объективных:
Возможность и простота покрытия тестами. Код, для которого сложно написать тесты, с множеством условий и внешних зависимостей, как правило, достаточно сложен для понимания и последующего внесения изменений. Если тестов нет, то изменения ещё и небезопасны.
Результаты статического анализа кода. Есть множество инструментов, анализирующих такие метрики, как cyclomatic/cognitive complexity. Они тоже не идеальны, но в целом дают неплохое представление о читабельности кода.
Эффективность же легко проверяется нагрузочными тестами.
Не, мне С нормально зашёл, и плюсы тоже. Таки время хорошо экономит. Но ассемблерные куски в ответственных местах случалось вставлять. Да и развернуть С(++) код в IDE, глянуть, что там под капотом – тоже порой дело не лишнее, добавляет понимания.
Был у нас один парень, написал ось реального времени под 8080, размером 384 байта, если мне память не изменяет. Вполне функциональную – выстраивала очереди задач, запускала на исполнение, управляла обменом сообщениями. Вытесняющей многозадачности не было, это да – но там нам и не надо было. Но Витя на ассемблере не то, что писал – он на нём думал 😁 Частенько в разговоре, чтобы объяснить идею, выдавал из головы листинги в 2-3 десятка строк.
Не только. Но когда была только, программеров всё равно было до странности много. Мне в разных источниках попадались цифры от 40 до 120 тысяч. Ума не приложу, чем такая толпа может заниматься. Особенно принимая во внимание жесточайший отбор – что, вроде бы, подразумевает и высочайшую квалификацию.
А может быть. Давно удивляюсь, напуркуа ФБ десятки тысяч программистов. Система-то, в общем, вполне примитивная по функционалу – лента новостей по сути, и не меняется особо долгие годы. Плюс ещё управление рекламами – тоже не космические технологии. Там с инфраструктурой сложно при таких нагрузках – это да. А большая часть кода вряд ли требует каких-то эксклюзивных скиллов, натренируют ИИ на задачках с leetcode и будет им щастье.
Вот только правила структурированности поменялись уже раз десять
Я же не о религиозных течениях, а о том, логично или нет организован код, понятен ли он, и легко ли его поддерживать. А такой результат может быть достигнут в различных парадигмах. И понимание этого, знакомство с различными подходами – как раз одно из преимуществ опытных специалистов. Например, молодёжь может искренне верить, что любой код должен быть SOLID, а на выходе будет fizz-buzz enterprise.
Да, я не отрицаю, что в каких-то случаях МС могут быть правильным решением. Просто это крайне редкие случаи – мне, например, пока сталкиваться не приходилось.
Да. Тоже собирался об этом написать, но пропустил. Точнее, у меня, например, есть некое общее ядро, неудачные изменения в котором теоретически могут вообще всё положить. Но такие вещи невозможно не заметить при тестировании, да и с микросервисами в этом случае произойдёт ровно то же самое. Если, разумеется, каждая МС команда не пишет его весь от начала до конца сама, изолированно – что свидетельствовало бы о крайне нерациональном использовании ресурсов.
Много как минимум спорных утверждений.
Что мне мешает добавить нужное количество нод на монолите? В том числе, динамически, по необходимости. Всё, что требуется – это поставить перед ними балансировщик нагрузки – который в высоконагруженных системах и так всегда уже есть.
Допустим, у меня есть команда, которая реализует обработку платежей, и ещё одна, которая занимается рассылкой мэйлов. Почему они должны ждать друг друга? Абсолютно несвязанный код, который можно релизить независимо. Если речь о бэке и фронте – так для того и придумали версионирование API, обратную совместимость и прочие техники, облегчающие независимую разработку модулей системы. Просто это должно быть продумано ещё на этапе проектирования.
Зоопарк технологий в одном проекте - скорее минус, нежели плюс.
____
А вот с перечисленными минусами микросервисов согласен абсолютно. И они настолько серьёзны, что переход на МС архитектуру должен быть очень хорошо обоснован, чтобы вообще в эту историю ввязываться.
А читая о том, что
никак не удаётся избавиться от ощущения, что система попросту плохо спроектирована. О чём тут речь, о типах сервисов или об инстансах? Второй случай ещё как-то можно понять – хотя боюсь, накладные расходы на запуск такого количества процессов и управление ими сами по себе съедят до фига ресурсов, и потребуют того самого горизонтального масштабирования гораздо раньше, чем в случае с монолитом. Тысячи типов объяснить не могу никак, не бывает систем такой сложности – если не лепить по 4 сервиса на каждую CRUD сущность.
Итого: думаю, что повальное увлечение микросервисами вряд ли обосновано. Есть случаи, когда они нужны – но это действительно очень большие, многофункциональные и высоконагруженные системы. Для абсолютного же большинства это ведет лишь к огромному усложнению инфраструктуры, сложность реализации которой и поддержания её в рабочем состоянии может значительно превышать выигрыш в сравнении с хорошо спроектированным монолитом.
Готов к приёму пинков от церкви свидетелей микросервисной архитектуры 😁
Нимрод же....
Да тоже вроде встречается:
Голосом рассказывать, правда, не умеет.
Ну почему сразу "отсутствие". Никогда не пробовал включать, ибо обычно моя задача – добраться до нужного пункта в незнакомом городе, и в таком случае отвлекаться на достопримечательности не очень получается, но вроде это оно и есть:
А если не голосом, то отображение POI на карте практически в любом навигаторе есть.
Трудно сказать. Отсутствие плюсов – тоже минус. Я, собственно, в основном о том, что в реальности минусы ставятся больше на эмоциях, нежели основываясь на содержании. Об этом и в статье написано – думаю, что оценке автора, имеющего доступ к аналитическим материалам ресурса, вполне можно верить. А если так, то они теряют изначальный смысл: борьбу с некачественным материалом силами сообщества.
А оно действительно важно? Честно говоря, отсутствие возможности ставить минусы не угнетает вообще. Более того, не уверен, что такая фича в принципе нужна. Минус (с моей точки зрения) заслуживает неприкрытое хамство или совсем уж неадекватный текст – и то, и другое на хабре встречается крайне редко. И с такими эксцессами скорее помогла бы бороться кнопка "послать модератору", а не минусы.
Дык, козу...
Не то, чтобы это было неверно, но на мой взгляд, не отражает некоторых важных нюансов. Дело в том, что это вот "готов приложить и развивать" – отнюдь не разовое состояние, а по сути непрерывное, от начала и до самого конца карьеры. Иначе в лучшем случае получится плохой программист, в худшем – никакого. "Закончу курсы, научусь и буду много зарабатывать" тут не прокатывает – практически обязательной является какая-никакая склонность именно к этому виду деятельности, желание погружаться в тему глубже и глубже – причём процесс этот должен доставлять удовольствие. Иначе через некоторое время неизбежно начнутся модные охи и ахи про "выгорание", "галеры" и прочую ахинею – которые на самом деле свидетельствуют лишь о том, что человек занимается не свойственным ему делом, за которое взялся либо в силу моды, либо под давлением родителей, либо в надежде начать много зарабатывать при умеренных усилиях.
Эффективность – штука тонкая. Она не должна быть максимально возможной – скорее достаточной. И честно говоря, в большинстве проектов вопрос эффективности не стоит вообще. Даже там, где она на самом деле важна, часто дешевле купить железо помощнее, чем оплачивать команду супер специалистов, умеющих в Hi Load. Как говаривал один заказчик: вам нужно ещё 100 гиг памяти? Я вам её куплю, но дайте мне результат к концу недели. Да и тестируемость тоже – круто иметь 100% покрытие, конечно, но чаще всего это просто избыточно.
Я бы предложил парочку в части понятности и поддерживаемости, вроде достаточно объективных:
Возможность и простота покрытия тестами. Код, для которого сложно написать тесты, с множеством условий и внешних зависимостей, как правило, достаточно сложен для понимания и последующего внесения изменений. Если тестов нет, то изменения ещё и небезопасны.
Результаты статического анализа кода. Есть множество инструментов, анализирующих такие метрики, как cyclomatic/cognitive complexity. Они тоже не идеальны, но в целом дают неплохое представление о читабельности кода.
Эффективность же легко проверяется нагрузочными тестами.
Бурные, продолжительные аплодисменты ©. Если ООП модель не DDD – с ней явно что-то не так. Сама концепция ООП сформировалась, как попытка представить бизнес-сущности средствами программирования. Всё остальное вторично.
Не, мне С нормально зашёл, и плюсы тоже. Таки время хорошо экономит. Но ассемблерные куски в ответственных местах случалось вставлять. Да и развернуть С(++) код в IDE, глянуть, что там под капотом – тоже порой дело не лишнее, добавляет понимания.
Был у нас один парень, написал ось реального времени под 8080, размером 384 байта, если мне память не изменяет. Вполне функциональную – выстраивала очереди задач, запускала на исполнение, управляла обменом сообщениями. Вытесняющей многозадачности не было, это да – но там нам и не надо было. Но Витя на ассемблере не то, что писал – он на нём думал 😁 Частенько в разговоре, чтобы объяснить идею, выдавал из головы листинги в 2-3 десятка строк.
Не только. Но когда была только, программеров всё равно было до странности много. Мне в разных источниках попадались цифры от 40 до 120 тысяч. Ума не приложу, чем такая толпа может заниматься. Особенно принимая во внимание жесточайший отбор – что, вроде бы, подразумевает и высочайшую квалификацию.
А может быть. Давно удивляюсь, напуркуа ФБ десятки тысяч программистов. Система-то, в общем, вполне примитивная по функционалу – лента новостей по сути, и не меняется особо долгие годы. Плюс ещё управление рекламами – тоже не космические технологии. Там с инфраструктурой сложно при таких нагрузках – это да. А большая часть кода вряд ли требует каких-то эксклюзивных скиллов, натренируют ИИ на задачках с leetcode и будет им щастье.
Тогда код придётся переписывать бесконечно. Ибо у каждого нового программиста ожидания свои.
Ну вот, а врут, что канбан изобрели японцы 😁
Я же не о религиозных течениях, а о том, логично или нет организован код, понятен ли он, и легко ли его поддерживать. А такой результат может быть достигнут в различных парадигмах. И понимание этого, знакомство с различными подходами – как раз одно из преимуществ опытных специалистов. Например, молодёжь может искренне верить, что любой код должен быть SOLID, а на выходе будет fizz-buzz enterprise.