Денис Цветцих - Модульный монолит вместо микросервисов: Как, когда и зачем

Подробнее о конференции DotNext: jrg.su/3WmFRE
- -
Микросервисы сегодня - это хайп, о котором говорят из каждого утюга. Складывается мнение, что старый добрый монолит - это плохо, а микросервисы - таблетка от всех болезней. Но так ли это на самом деле?
В своем докладе Денис расскажет о том, когда стоит предпочесть монолит микросервисам. А также о том, что монолиты бывают разные, это не обязательно большой комок грязи. Модульный монолит позволяет сделать такую же качественную изоляцию частей системы друг от друга, как это предлагают микросервисы, при этом сохранив простоту отладки, деплоя и работу в рамках одной транзакции. Да, писать хорошие монолиты тоже нужно уметь :)
Также спикер расскажет, когда обычному монолиту пора становиться модульным и как перейти от обычного монолита к модульному. И, конечно, как выделять модули в отдельные сервисы.
Скачать презентацию: assets.ctfasse...

[@kurnakovv]

00:22 Как появилась идея такого доклада 02:08 Что такое Dev brothers 02:40 Почему на презентации без бороды 03:00 Начало доклада 04:00 Вопросы агитаторам за микросервисы 04:35 Архитектурные тренды 06:10 Как сейчас воспринимается монолит/микросервисы 07:06 О чем поговорим 07:33 Что такое монолит 08:34 Достоинства монолитов 09:10 Недостатки монолита 10:24 Реальные преимущества микросервисов (Рихтер) 12:03 Независимое масштабирование - самое главное 13:06 Когда используют микросервисы 13:40 "Микросервисы, но" в Enterprise 14:42 Когда делать монолиты 15:47 Как ускорять монолиты 17:20 Зачем нужен модульный монолит 21:50 Пример 23:10 Схема архитектуры модульного монолита 24:18 Сходство с микросервисами/плагинами 25:20 Что делает хост 26:13 Нужен ли инициализатор модуля? 27:09 Доступ к данным 30:50 Проект на C# 34:56 Почему не доменные события? 35:40 Атомарность транзакции 39:10 Кейс: финтех-проект 42:45 Инфраструктура 44:49 Что еще изменится при переходе в модульный монолит 48:30 Нужно ли всё это? 50:33 Итоги 52:50 Доп. источники 55:00 Вопросы

[@frimuchkov]

Вот прям в точку! Сам недавно открыл для самого себя, что микросервисы не так уж и полезны, как кажется. Полез искать, додумались ли до меня и нашёл это видео. Так, как мой основной стек - NodeJS, то идеальный расклад выглядит так: - Модульный монолит на NodeJS - HightLoad-сервисы или сервисы, от которых требуются особые гарантии пишутся в качестве микросервисов на Go/Rust/C++ - Общие библиотеки выносятся пишутся на Go/Rust/C++ и доставляются в монолит как WEBASM-либы UPD. Для меня "модульный монолит" это когда одна кодовая база и одна база данных, при этом мы можем запускать n инстансов и даже как-то хитро нагрузку роутить

[@Konservator69]

Интересное и доходчивое изложение, спасибо. Искал идеи того, как на новой работе разбить типичный легаси-спагетти-монстр на отдельные сервисы, пусть даже и SOA, не микро. Модульный монолит - это и очень удобный промежуточный шаг для перехода к ним и, одновременно, неплохая альтернатива, если выяснится что для твоего проекта микросервисы архитектурно избыточны. К некоторым моментам доклада можно, безусловно, придраться. Например, автор забыл сказать, что монолит - это еще и single point of failure, в то время как разбиение на отдельные сервисы позволяет минимизировать последствия падения одного из них. Отвалится только часть функциональности, но в целом система продолжить жить. Ну да ладно, всё остальное отлично рассказано.

[@boyarynov]

Отлично изложил мысли. Как раз искал как решить проблему работы многих команд в одном монолите

[@KabukiWarrior369]

взвешенный, опытный взгляд на проблему

[@alexeykonovalenko6965]

спасибо за отличный доклад. действительно, на начальных этапах стартапов, монолит реально ускоряет разработку и не нужны супер квалифицированные спецы. но узким местом монолитных модульных систем является общая база данных, кол-во запросов/транзакций которые сможет обработать БД и является проблемой высоконагруженных монолитов. кешировнаие, зеркалирование БД приводит к решению проблем со скоростью синхронизации данных. и вот тогда нужна очень квалификацированная команда, чтобы добиться максимального перфоманса при минимилизации потребления ресурсов. ну а когда тюнинг не помагает, начинаются разговоры о переходы на микросервисы :-) но это обычно уже делает другая команда

[@VoroninPavel]

> но узким местом монолитных модульных систем является общая база данных Но это же необязательное условие, можно и разные БД под каждый модуль иметь. > монолит реально ускоряет разработку и не нужны супер квалифицированные спецы. Как бы да, но есть нюанс. Изначально модульность должна быть организована так, чтоб порушить границы между модулями было сложно. К сожалению Architecture constaints - это фича enterprise VS =( В принципе, сейчас можно поискать какой-нибудь Рослин-анализтатор.

[@sanphir]

Узость места зависит от проектирования БД и её архитектуры

[@sagamoreBel]

Ссылка на скачивание презентации не работает

[@xelaksal6690]

Есть ощущение что весь подход модульного монолита это преждевременная оптимизация. Это конечно не значит что это плохой подход, скорее наоборот - это лучший по соотношению затрат и расширяемости в будущем, как мне кажется.

[@xelaksal6690]

Я это к тому что потенциально много точек где можно схалтурить или сделать неправильно, но это наверно больше вопрос инженерной культуры.

[@MrCommanderKid]

Только смузи, только, сигвэй, только микросервисы, но Хипстеры вымерли