Ночной кошмар Мартина Фаулера - из кота вылезает сервис уборной для кота. Но к концу кошмар сменяется умиротворением - сухая еда это не сервис а заботливо переданный честный объект 😂
Если я правильно понял принцип, то что-то неприятное лучше выносить в сервисы и принимать не сами объекты, а айдишники, чтобы случайно их не запачкать, а приятное наоборот заботливо передавать объектом в конструкторе, поближе, так сказать, к полям. 🤗
Этому багу 30 лет. Я согласен с автором в том смысле, что выбрасываемые в рантайме UnsupportedOperationException - это зло и в sdk по-хорошему такого не должно быть в принципе, эти вещи нужно проверять в момент компиляции. Для этого исходные интерфейсы наверно стоило бы спроектировать по-другому изначально, например можно было бы базовый Collection разбить на несколько интерфейсов. Но это всё дела давно минувших дней, сейчас радикально поменять это уже нельзя. А что касается sequenced collections, то они сделаны вполне неплохо, на мой взгляд сильно не портят то, что уже было, и помогают в местах, где до этого был бойлерплейт/велосипеды.
Про память это условно, всё зависит от особенностей приложения, если у вас 32гб монолит, но масштабируетесь вы потому, что у вас на один эндпоинт, который потребляет при вызове 100 байт, миллион запросов в секунду, а остальное приложение просто пассивно висит в памяти, то да действительно скейлить всё приложение только ради одного эндпоинта странно и его нужно выносить. Однако если у вас нагрузка +- гомогенна на всё приложение, то распилив эти 32 гигабайта по микросервисам вы не получите преимуществ с точки зрения памяти, а скорее наоборот, поскольку помимо полезной нагрузки отдельные рантаймы будут потреблять память в то время как в монолите рантайм потребляет память один раз.
Что касается ресурсов, например коннекшенов, то здесь я соглашусь, за этим надо внимательно следить при масштабировании монолита, это может вызвать проблему, особенно если внешних ресурсов много и каждый из них используется только одним модулем. С другой стороны, например, если у вас подключение к одной базе, используется connection pool и модули работают с разными схемами, то как и в случае с памятью распилив приложение вы не получите преимуществ, а скорее наоборот.
Приведите, пожалуйста, пример. В общем случае это не так и зависит от платформы. Если у вас есть монолит, например на java, который потребляет 8Гб памяти, то распилив его, суммарная потребляемая память увеличится, поскольку для каждого микросервиса помимо полезной нагрузки будет подниматься отдельный jvm рантайм, потребляющий память. В случае монолита, такой рантайм только один.
Если это какой-то междусобойчик для просветленных, то зачем он в паблике на хабре. Если нет, то непонятно как минимум ничего. Почему отказ от транзакций? Какая государственная система? Причем здесь Эльбрус? Чем автора не устроила производительность jvm, какой версии и с чем он сравнивал?
С автором статьи согласен в том смысле, что менеджеры гораздо чаще воспринимают скрам как волшебную палочку, которая позволяет "за две недели сделать всё, что написано" (хотя, как подчеркивают многие комментаторы, методология на этом не настаивает). Если же команда работает по канбану, то шанс увидеть адекватного менеджера выше.
Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.
Модульный монолит не про транзакции, он решает другую проблему - устраняет необходимость поддерживать медиаторы типа сервис меша, очередей, инфраструктуры для всего этого, поддерживать и мучаться с разными версиями сервисов, их разными жизненными циклами и так далее. Когда взаимодействие идёт просто через память без посредников, то о посредниках не надо думать, и это экономит много времени. Для небольших и средних компаний это бывает важно. Что касается транзакций, то если вы хотите делать транзакции между модулями, то возможно стоит перепроектировать.
В целом с автором согласен - "диктатура микросервисов" второй половины 10х годов - это штука ужасная и скольким командам она принесла больше вреда, чем пользы не перечесть, так что популяризация модульного монолита - это на мой взгляд действительно благо для индустрии. Что касается части про AI я не очень согласен, на своей практике даже если команда работала в рамках модульного монолита, AI/ML модули обычно выносили в отдельные сервисы со своим рантаймом по разным причинам, например потому что язык был другой или не хотелось тянуть очень тяжелые зависимости в основной бинарник и т.д.
Не совсем корректно смешивать классический монолит и модульный(композитный) монолит. В первом обычно из любого места проекта видно весь остальной проект, программисты активно этим пользуются и чем дольше, тем хуже клубок зависимостей получается, код становится неподдерживаемым. Модульный монолит фактически организован как микросервисы и вы не можете в любом месте использовать весь проект, только некоторую часть, которая доступна для этого места. Но при этом за счет композиции модулей в один бинарник, в котором разные модули общаются через память, вам не нужно тратить значительные ресурсы на организацию работы, версионирование и взаимодействие, что обычно происходит в случае микросервисов. Тем не менее, что важно - в грамотно организованном модульном монолите при желании вы легко можете собрать из модулей и несколько сервисов, просто заменив реализации контрактов их взаимодействия и не переписывая половину проекта.
Статья не показалась мне цельной и не все выводы как мне кажется следуют из того, что написано. А вот, что точно - ни аджайл, ни скрам сами по себе не приведут к качественному продукту, к нему приводят конкретные люди, а не абстрактные команды. За много лет в разработке не раз видел примеры, когда плохие команды делали плохой продукт по самой модной на тот момент методологии и наоборот команды из хороших специалистов используя самопальную методологию-мутанта, придуманную за обедом, делали и поддерживали очень качественные продукты.
Я обычно использую немного другой подход для "одноразовых скриптов", а точнее просто небольших утилит для личного пользования, которых может быть много. У мавена есть возможность делать мультимодульные проекты, в которых модули организованы иерархически. Модули могут иметь свои зависимости, работать на разных версиях jvm и т.д, а иерархия может добавлять общие настройки группам модулей. Современные IDE вроде IDEA отлично работают с такими проектами. Используя этот подход, все вспомогательные утилиты я много лет складываю в один проект, в котором сейчас 172 модуля. Конфигурации запуска я также группирую иерархически для удобства работы. Поскольку всё это происходит в рамках одного проекта, то с одной стороны доступны все возможности IDE по работе с кодом, а, с другой, вы всегда можете в случае необходимости переиспользовать какой-то код, просто добавив зависимость и убедившись, что они на одной версии рантайма.
Звучит возможно тяжеловесно для "скриптов", но это было вполне сознательное решение после того, как с одной стороны я устал от хаоса при работе со скриптами на скриптовых языках, а с другой периодически появлялась потребность переиспользования кода, которая обычно в мире скриптов решалась копипастой, что добавляло головной боли, если скрипты оказывались не такими "одноразовыми", какими казались вначале.
На универсальность такого подхода не претендую, но лично мне он помог навести порядок.
Ночной кошмар Мартина Фаулера - из кота вылезает сервис уборной для кота. Но к концу кошмар сменяется умиротворением - сухая еда это не сервис а заботливо переданный честный объект 😂
Если я правильно понял принцип, то что-то неприятное лучше выносить в сервисы и принимать не сами объекты, а айдишники, чтобы случайно их не запачкать, а приятное наоборот заботливо передавать объектом в конструкторе, поближе, так сказать, к полям. 🤗
Этому багу 30 лет. Я согласен с автором в том смысле, что выбрасываемые в рантайме UnsupportedOperationException - это зло и в sdk по-хорошему такого не должно быть в принципе, эти вещи нужно проверять в момент компиляции. Для этого исходные интерфейсы наверно стоило бы спроектировать по-другому изначально, например можно было бы базовый Collection разбить на несколько интерфейсов. Но это всё дела давно минувших дней, сейчас радикально поменять это уже нельзя. А что касается sequenced collections, то они сделаны вполне неплохо, на мой взгляд сильно не портят то, что уже было, и помогают в местах, где до этого был бойлерплейт/велосипеды.
Про память это условно, всё зависит от особенностей приложения, если у вас 32гб монолит, но масштабируетесь вы потому, что у вас на один эндпоинт, который потребляет при вызове 100 байт, миллион запросов в секунду, а остальное приложение просто пассивно висит в памяти, то да действительно скейлить всё приложение только ради одного эндпоинта странно и его нужно выносить. Однако если у вас нагрузка +- гомогенна на всё приложение, то распилив эти 32 гигабайта по микросервисам вы не получите преимуществ с точки зрения памяти, а скорее наоборот, поскольку помимо полезной нагрузки отдельные рантаймы будут потреблять память в то время как в монолите рантайм потребляет память один раз.
Что касается ресурсов, например коннекшенов, то здесь я соглашусь, за этим надо внимательно следить при масштабировании монолита, это может вызвать проблему, особенно если внешних ресурсов много и каждый из них используется только одним модулем. С другой стороны, например, если у вас подключение к одной базе, используется connection pool и модули работают с разными схемами, то как и в случае с памятью распилив приложение вы не получите преимуществ, а скорее наоборот.
Приведите, пожалуйста, пример. В общем случае это не так и зависит от платформы. Если у вас есть монолит, например на java, который потребляет 8Гб памяти, то распилив его, суммарная потребляемая память увеличится, поскольку для каждого микросервиса помимо полезной нагрузки будет подниматься отдельный jvm рантайм, потребляющий память. В случае монолита, такой рантайм только один.
Если это какой-то междусобойчик для просветленных, то зачем он в паблике на хабре. Если нет, то непонятно как минимум ничего. Почему отказ от транзакций? Какая государственная система? Причем здесь Эльбрус? Чем автора не устроила производительность jvm, какой версии и с чем он сравнивал?
А в чем вы видите проблему горизонтально масштабировать монолит?
С автором статьи согласен в том смысле, что менеджеры гораздо чаще воспринимают скрам как волшебную палочку, которая позволяет "за две недели сделать всё, что написано" (хотя, как подчеркивают многие комментаторы, методология на этом не настаивает). Если же команда работает по канбану, то шанс увидеть адекватного менеджера выше.
Когда на 100 микросервисов одна команда из 10 человек - это тоже проблема
Когда над монолитом работает сотня команд - это проблема
Масштабировать монолит по rps в сотне инстансов не проблема.
Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
И как эти бинари взаимодействуют?
Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.
Модульный монолит не про транзакции, он решает другую проблему - устраняет необходимость поддерживать медиаторы типа сервис меша, очередей, инфраструктуры для всего этого, поддерживать и мучаться с разными версиями сервисов, их разными жизненными циклами и так далее. Когда взаимодействие идёт просто через память без посредников, то о посредниках не надо думать, и это экономит много времени. Для небольших и средних компаний это бывает важно. Что касается транзакций, то если вы хотите делать транзакции между модулями, то возможно стоит перепроектировать.
В целом с автором согласен - "диктатура микросервисов" второй половины 10х годов - это штука ужасная и скольким командам она принесла больше вреда, чем пользы не перечесть, так что популяризация модульного монолита - это на мой взгляд действительно благо для индустрии. Что касается части про AI я не очень согласен, на своей практике даже если команда работала в рамках модульного монолита, AI/ML модули обычно выносили в отдельные сервисы со своим рантаймом по разным причинам, например потому что язык был другой или не хотелось тянуть очень тяжелые зависимости в основной бинарник и т.д.
Не совсем корректно смешивать классический монолит и модульный(композитный) монолит. В первом обычно из любого места проекта видно весь остальной проект, программисты активно этим пользуются и чем дольше, тем хуже клубок зависимостей получается, код становится неподдерживаемым. Модульный монолит фактически организован как микросервисы и вы не можете в любом месте использовать весь проект, только некоторую часть, которая доступна для этого места. Но при этом за счет композиции модулей в один бинарник, в котором разные модули общаются через память, вам не нужно тратить значительные ресурсы на организацию работы, версионирование и взаимодействие, что обычно происходит в случае микросервисов. Тем не менее, что важно - в грамотно организованном модульном монолите при желании вы легко можете собрать из модулей и несколько сервисов, просто заменив реализации контрактов их взаимодействия и не переписывая половину проекта.
Статья не показалась мне цельной и не все выводы как мне кажется следуют из того, что написано. А вот, что точно - ни аджайл, ни скрам сами по себе не приведут к качественному продукту, к нему приводят конкретные люди, а не абстрактные команды. За много лет в разработке не раз видел примеры, когда плохие команды делали плохой продукт по самой модной на тот момент методологии и наоборот команды из хороших специалистов используя самопальную методологию-мутанта, придуманную за обедом, делали и поддерживали очень качественные продукты.
Я обычно использую немного другой подход для "одноразовых скриптов", а точнее просто небольших утилит для личного пользования, которых может быть много. У мавена есть возможность делать мультимодульные проекты, в которых модули организованы иерархически. Модули могут иметь свои зависимости, работать на разных версиях jvm и т.д, а иерархия может добавлять общие настройки группам модулей. Современные IDE вроде IDEA отлично работают с такими проектами. Используя этот подход, все вспомогательные утилиты я много лет складываю в один проект, в котором сейчас 172 модуля. Конфигурации запуска я также группирую иерархически для удобства работы. Поскольку всё это происходит в рамках одного проекта, то с одной стороны доступны все возможности IDE по работе с кодом, а, с другой, вы всегда можете в случае необходимости переиспользовать какой-то код, просто добавив зависимость и убедившись, что они на одной версии рантайма.
Звучит возможно тяжеловесно для "скриптов", но это было вполне сознательное решение после того, как с одной стороны я устал от хаоса при работе со скриптами на скриптовых языках, а с другой периодически появлялась потребность переиспользования кода, которая обычно в мире скриптов решалась копипастой, что добавляло головной боли, если скрипты оказывались не такими "одноразовыми", какими казались вначале.
На универсальность такого подхода не претендую, но лично мне он помог навести порядок.