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 Вопросы
Вот прям в точку! Сам недавно открыл для самого себя, что микросервисы не так уж и полезны, как кажется. Полез искать, додумались ли до меня и нашёл это видео. Так, как мой основной стек - NodeJS, то идеальный расклад выглядит так: - Модульный монолит на NodeJS - HightLoad-сервисы или сервисы, от которых требуются особые гарантии пишутся в качестве микросервисов на Go/Rust/C++ - Общие библиотеки выносятся пишутся на Go/Rust/C++ и доставляются в монолит как WEBASM-либы UPD. Для меня "модульный монолит" это когда одна кодовая база и одна база данных, при этом мы можем запускать n инстансов и даже как-то хитро нагрузку роутить
Интересное и доходчивое изложение, спасибо. Искал идеи того, как на новой работе разбить типичный легаси-спагетти-монстр на отдельные сервисы, пусть даже и SOA, не микро. Модульный монолит - это и очень удобный промежуточный шаг для перехода к ним и, одновременно, неплохая альтернатива, если выяснится что для твоего проекта микросервисы архитектурно избыточны. К некоторым моментам доклада можно, безусловно, придраться. Например, автор забыл сказать, что монолит - это еще и single point of failure, в то время как разбиение на отдельные сервисы позволяет минимизировать последствия падения одного из них. Отвалится только часть функциональности, но в целом система продолжить жить. Ну да ладно, всё остальное отлично рассказано.
спасибо за отличный доклад. действительно, на начальных этапах стартапов, монолит реально ускоряет разработку и не нужны супер квалифицированные спецы. но узким местом монолитных модульных систем является общая база данных, кол-во запросов/транзакций которые сможет обработать БД и является проблемой высоконагруженных монолитов. кешировнаие, зеркалирование БД приводит к решению проблем со скоростью синхронизации данных. и вот тогда нужна очень квалификацированная команда, чтобы добиться максимального перфоманса при минимилизации потребления ресурсов. ну а когда тюнинг не помагает, начинаются разговоры о переходы на микросервисы :-) но это обычно уже делает другая команда
> но узким местом монолитных модульных систем является общая база данных Но это же необязательное условие, можно и разные БД под каждый модуль иметь. > монолит реально ускоряет разработку и не нужны супер квалифицированные спецы. Как бы да, но есть нюанс. Изначально модульность должна быть организована так, чтоб порушить границы между модулями было сложно. К сожалению Architecture constaints - это фича enterprise VS =( В принципе, сейчас можно поискать какой-нибудь Рослин-анализтатор.
Есть ощущение что весь подход модульного монолита это преждевременная оптимизация. Это конечно не значит что это плохой подход, скорее наоборот - это лучший по соотношению затрат и расширяемости в будущем, как мне кажется.
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 Вопросы
Отлично изложил мысли. Как раз искал как решить проблему работы многих команд в одном монолите
взвешенный, опытный взгляд на проблему
Вот прям в точку!
Сам недавно открыл для самого себя, что микросервисы не так уж и полезны, как кажется. Полез искать, додумались ли до меня и нашёл это видео.
Так, как мой основной стек - NodeJS, то идеальный расклад выглядит так:
- Модульный монолит на NodeJS
- HightLoad-сервисы или сервисы, от которых требуются особые гарантии пишутся в качестве микросервисов на Go/Rust/C++
- Общие библиотеки выносятся пишутся на Go/Rust/C++ и доставляются в монолит как WEBASM-либы
UPD. Для меня "модульный монолит" это когда одна кодовая база и одна база данных, при этом мы можем запускать n инстансов и даже как-то хитро нагрузку роутить
Интересное и доходчивое изложение, спасибо. Искал идеи того, как на новой работе разбить типичный легаси-спагетти-монстр на отдельные сервисы, пусть даже и SOA, не микро. Модульный монолит - это и очень удобный промежуточный шаг для перехода к ним и, одновременно, неплохая альтернатива, если выяснится что для твоего проекта микросервисы архитектурно избыточны.
К некоторым моментам доклада можно, безусловно, придраться. Например, автор забыл сказать, что монолит - это еще и single point of failure, в то время как разбиение на отдельные сервисы позволяет минимизировать последствия падения одного из них. Отвалится только часть функциональности, но в целом система продолжить жить. Ну да ладно, всё остальное отлично рассказано.
Ссылка на скачивание презентации не работает
спасибо за отличный доклад. действительно, на начальных этапах стартапов, монолит реально ускоряет разработку и не нужны супер квалифицированные спецы. но узким местом монолитных модульных систем является общая база данных, кол-во запросов/транзакций которые сможет обработать БД и является проблемой высоконагруженных монолитов. кешировнаие, зеркалирование БД приводит к решению проблем со скоростью синхронизации данных. и вот тогда нужна очень квалификацированная команда, чтобы добиться максимального перфоманса при минимилизации потребления ресурсов. ну а когда тюнинг не помагает, начинаются разговоры о переходы на микросервисы :-) но это обычно уже делает другая команда
> но узким местом монолитных модульных систем является общая база данных
Но это же необязательное условие, можно и разные БД под каждый модуль иметь.
> монолит реально ускоряет разработку и не нужны супер квалифицированные спецы.
Как бы да, но есть нюанс. Изначально модульность должна быть организована так, чтоб порушить границы между модулями было сложно. К сожалению Architecture constaints - это фича enterprise VS =( В принципе, сейчас можно поискать какой-нибудь Рослин-анализтатор.
Узость места зависит от проектирования БД и её архитектуры
Есть ощущение что весь подход модульного монолита это преждевременная оптимизация. Это конечно не значит что это плохой подход, скорее наоборот - это лучший по соотношению затрат и расширяемости в будущем, как мне кажется.
Я это к тому что потенциально много точек где можно схалтурить или сделать неправильно, но это наверно больше вопрос инженерной культуры.
Только смузи, только, сигвэй, только микросервисы, но Хипстеры вымерли