Я очень рад, что в реакте вводятся хуки. Это снимет много головной боли связанной с типизацией HoC и вообще необходимостью делить компоненты везде, а не только где надо.
Но вот то, что их в циклах использовать нельзя — это ужасно. Такая себе протекающая абстракция.
Если ваше понимание говорит о том, что монолит нельзя масштабировать, то это неправильное понимание.
Да, я принимал участие в разработке трех проектов на микросервисной архитектуре. Из этого негативного опыта у меня вылазит огромное смущение по поводу популярности этой хлипкой идеи.
Вот это лол. Вы неявно обвиняете чувака в недостатке практики. Но при этом:
1) вы не представляете как масштабировать монолит;
2) сами не имеете практики участия в проектах с архитектурой похожей на микросервисную.
Ваше безаппеляционное заявление привязано к вашему личному опыту. Как мне кажется, именно за это и минусят вас.
Но вы мне скажите один момент. Микросервисы в общем-то недавняя тема (если смотреть по взрыву популярности). Как до этого момента люди делали сложные приложения?
Встряну, пожалуй. Вы показываете серьезный недостаток в теории и при этом аппелируете к практике, чудно. Проблема в том, что знание теории видно из беседы, а практика скорее всего лежит под NDA.
К примеру, я учавствовал в разработке серьезных проектов. Монолит нисколько не мешал. Но откуда вам знать, что я не соврал?
Зы: вы же не думаете, что люди защищающие монолит защищают отсутствие модульности?
Оверхед тут в том, что приходится использовать лишнее хранилище, хотя если это было одно приложение то можно было бы эти данные хранить и сортировать в памяти, без использования очередей.
С очередью в памяти очень трудно добиться либо гарантий persistance, либо гарантий exactly-once. Все еще оверхед?
И по сути БД или MQ это микросервис
Вы уверены, что БД можно считать микросервисом? Просто одно из свойств правильно приготовленных микросервисов заключается в том, что можно делать независимое обновление и деплой микросервисов.
Вообще мне этот комментарий доставляет. Такое впечатление, будто вы думаете, что микросервис — это модуль, общающийся по сети.
Микросервис — изолированный код, который может деплоиться независимо
Монолит — скорее всего не изолированный код, который скорее всего не может деплоиться независимо.
Если вам кажется глупым складировать сообщения в очередь в рамках монолита, то это скорее ваша проблема, чем проблема концепции монолита. Если есть требования, которые требуют очереди, то почему бы и не юзать очереди? Если вам для оправдания очереди приходится подключать еще что-то кроме требований, то это ваша проблема.
Кроме того, вы рассматриваете понятие «оверхед» только в контексте «мне почему-то кажется эта операция ненужной». Но если операция реально нужна, то это не оверхед, а просто неприятность.
Как мне кажется, большинство этих вещей программисту средней руки не особо пригодится. Зато эти вещи сделают код библиотек более быстрым и менее требовательным к ресурсам. Сплошная выгода.
Я там вижу две темы:
— Хейт неоправданной абстракции, т.е. когда абстракция начинает приносить больше проблем, чем решать.
— Хейт маркетинга, который врет о том, что новые штуки кардинально изменят жизнь, тогда как на самом деле они проводят только локальное улучшение.
Ну мы находимся в топике про микросервисы и обсуждаем недостатки монолита по сравнению с микросервисами.
Хочу отметить, что при разделении приложения таким образом мы вовсе не обязаны разделять кодовую базу. Особенно если хотим шарить общую бизнес-логику. В таком случае код куда ближе к монолитам.
Я видел приложение, которое гоняло между микросервисами файлы объемом 1-100 мегабайт в рамках одного API-запроса десяток раз. Даже на локальной машине это жутко тупило. Но это эпик случай.
Задержка для сетевого обмена данных складывается из сериализации и десериализации данных, скорости передачи данных, пинга. В лучшем случае это числа порядка миллисекунд. В худшем случае число может достигать порядка десятков миллисекунд (а то и сотни).
Для сложного приложения эти числа нужно умножать в пару раз, потому что происходит больше одного общения.
А что мешает настроить балансировщик так, чтобы он определенные запросы отправлял строго на один конкретный инстанс?
Во многом получится тоже самое, но без модульности.
Я очень рад, что в реакте вводятся хуки. Это снимет много головной боли связанной с типизацией HoC и вообще необходимостью делить компоненты везде, а не только где надо.
Но вот то, что их в циклах использовать нельзя — это ужасно. Такая себе протекающая абстракция.
То, что ядро линукса является только частью большой головоломки, это замечательно.
Но это не отменяет того, что оно сложное и большое. Поэтому его можно рассматривать в качестве примера.
Ага. Например, ядро линукса, движок v8, или компилятор достаточно сложного языка.
Хорошо, давайте зайдем с другой стороны. Как разрабатываются сложные приложения вне веба? Тоже сервисы/микросервисы?
Пожалуйста, забудьте учебник демагогии. Это реально раздражает.
То, что, внутри этих компаний может быть применяются микросервисы еще не значит, что нет сложных монолитов.
Хорошо, мы уже пришли к сервисам. Вы уверены, что все сложные приложения делались на основе сервисов?
Да, я принимал участие в разработке трех проектов на микросервисной архитектуре. Из этого негативного опыта у меня вылазит огромное смущение по поводу популярности этой хлипкой идеи.
1) вы не представляете как масштабировать монолит;
2) сами не имеете практики участия в проектах с архитектурой похожей на микросервисную.
Вы не находите в этом ничего смешного?
Но вы мне скажите один момент. Микросервисы в общем-то недавняя тема (если смотреть по взрыву популярности). Как до этого момента люди делали сложные приложения?
К примеру, я учавствовал в разработке серьезных проектов. Монолит нисколько не мешал. Но откуда вам знать, что я не соврал?
Зы: вы же не думаете, что люди защищающие монолит защищают отсутствие модульности?
Вы уверены, что БД можно считать микросервисом? Просто одно из свойств правильно приготовленных микросервисов заключается в том, что можно делать независимое обновление и деплой микросервисов.
Вообще мне этот комментарий доставляет. Такое впечатление, будто вы думаете, что микросервис — это модуль, общающийся по сети.
Монолит — скорее всего не изолированный код, который скорее всего не может деплоиться независимо.
Если вам кажется глупым складировать сообщения в очередь в рамках монолита, то это скорее ваша проблема, чем проблема концепции монолита. Если есть требования, которые требуют очереди, то почему бы и не юзать очереди? Если вам для оправдания очереди приходится подключать еще что-то кроме требований, то это ваша проблема.
Кроме того, вы рассматриваете понятие «оверхед» только в контексте «мне почему-то кажется эта операция ненужной». Но если операция реально нужна, то это не оверхед, а просто неприятность.
— Хейт неоправданной абстракции, т.е. когда абстракция начинает приносить больше проблем, чем решать.
— Хейт маркетинга, который врет о том, что новые штуки кардинально изменят жизнь, тогда как на самом деле они проводят только локальное улучшение.
А что видите вы?
Хочу отметить, что при разделении приложения таким образом мы вовсе не обязаны разделять кодовую базу. Особенно если хотим шарить общую бизнес-логику. В таком случае код куда ближе к монолитам.
Задержка для сетевого обмена данных складывается из сериализации и десериализации данных, скорости передачи данных, пинга. В лучшем случае это числа порядка миллисекунд. В худшем случае число может достигать порядка десятков миллисекунд (а то и сотни).
Для сложного приложения эти числа нужно умножать в пару раз, потому что происходит больше одного общения.
Это вовсе не пренебрежимо малая задержка.
Во многом получится тоже самое, но без модульности.
Но ваши примеры становятся все лучше и лучше
Простите, я ничерта не понял из вашей картинки
А в чем ключевые различия этой задачи при монолите и при микросервисной архитектуре?
В таком случае я могу свободно нарекать себя разработчиком в проектах на микросервисной архитектуре. Но боюсь, на собеседовании меня не поймут