Modular Monolith: Is This the Trend in Software Architecture? (Рубрика Architecture)
Интересный и короткий whitepaper на тему модульных монолитов, который задает вопрос насчет их трендовости. Авторы статьи сделили Systematic Grey Literature Review (SGLR) для анализа этого вопроса. По-факту, это анализ материалов, не прошедшие коммерческое академическое издание (отчёты ведомств и НКО, диссертации, доклады конференций, технические спецификации, preprint-репозитории, сайты проектов и т. д.). Они пытались понять насколько распространены модульные монолиты, стратегически сочетающие простоту разработки традиционных монолитов с преимуществами масштабируемости микросервисов, предлагая альтернативу, избегающую сложностей распределенных систем при сохранении модульных принципов. Вопрос был в том, а сможет ли modular monolith стать жизнеспособным компромиссом, дающим "лучшее из двух миров".Исследование мотивировано анонсом фреймворка Service Weaver от Google, позволяющего писать приложения как модульные монолиты с возможностью микросервисного деплоя. Интересно, что сам Service Weaver от Google и ответил на этот вопрос - с 6 июня он отправится в архив, не достигнув нужного уровня adoption.
Но если возвращаться к самому whitepaper, то авторы пытались показать, что modular monolith обеспечивает:
- Сохранение скорости разработки, характерной для монолитов
- Четкие границы модулей, предотвращающие эволюцию в "big ball of mud"
- Гибкость использования как самостоятельной архитектуры или промежуточного этапа перед микросервисами
- Упрощение процессов отладки и тестирования
- Эффективное масштабирование команд через распределение модулей
Из исследования литературы они выделили следующие ключевые характеристики модульных монолитов - Segregation of modules: независимые модули с собственными слоями (Domain, Infrastructure, API) - Modularity: слабая связность и сильная связность внутри модулей, асинхронная коммуникация через API - Unified Database Schema: единая схема БД вместо отдельных схем на сервис - Monolithic Deployment: все модули работают в рамках одной VM или распределены по выделенным VM - Unified Application Process: единый процесс приложения для всех масштабов - Enhanced Maintainability: измеримое улучшение поддерживаемости vs традиционные монолиты
В самом исследовании отмечалось, что известнейшими компаниями с модульными монолитами являются Shopify, Appsmith, Gusto, PlayTech, правда, они не использовали Service Weaver.
P.S. Если отходить от самого whitepaper и оценить проблемы, что привели к закрытию Service Weaver, то можно отметить следующие 1) Низкий adoption rate - по-факту, это написано на странице проекта в аргументации к его закрытию
We realized that it was hard for users to adopt Service Weaver directly since it required rewriting large parts of existing applications. Therefore, Service Weaver did not see much direct use, and effective December 5, 2024, we will transition Service Weaver into maintenance mode. 2) Только go стек, что сужало целевую аудиторию 3) Опасность абстракций, когда локальный вызов может внезапно стать RPC (remote procedure call) - этим weaver напоминал концепцию CORBA/RMI, которая еще 20 лет назад показала свою непрактичность 4) Недостаточная функциональность - в фреймворке не было готовой маршрутизации/retries как в service mesh, нет встроенной mtls, нет удобного мониторинга 5) Конкуренция внутри самого Google Cloud - большинство кейсов, где weaver помогал пользователи уже решали через Cloud Run, GKE Autopilot + Istio или Functions, то есть им было проще использовать привычный стек, чем учить новую CLI и TOML-конфиги Weaver
Итого, интересная идея не полетела из-за того, что не набрала критической массы пользователей, а также не предложила ответа на концептуальные вопросы вида local/remote procedure calls и их неполное соответствие друг друга в плане НФТ при разных видах deployments. Но для любителей модульных монолитов остались фреймворки вида Spring Modulith.
#Architecture #Whitepaper #DistributedSystems #SystemDesign #Software #Engineering