Монолитная архитектура

• Монолитная архитектура
  • Зачем
  • Плюсы и минусы
    • Проблема монолита данных
  • Паттерны
    • Ускорение монолита
  • Антипаттерны
    • Распределенный монолит

Зачем

• MVP модульный монолит, который затем можно разделить на сервисы в MSA

Плюсы и минусы

Критерии

Плюсы:

• Mvp
• Межмодульный рефакторинг
• Согласованность
• Скорость реализации
• Дешевле инфраструктура, реализация
• Приступая к созданию приложения, нужно изначально придерживаться единой архитектуры — по причине её простоты. В то же время нужно стараться создавать его как можно более модульным, чтобы каждый компонент легко переносился в отдельный микросервис

Минусы:

• Регресс
• Долго деплоить и откатывать
• Высокая связность - решение модульный монолит, DDD
• проблема трех монолитов:
  • монолита приложений
  • интеграционного монолита
  • монолита данных
• наличие единой точки отказа (в случае сбоя в одном из модулей приложения отказывает все приложение и останавливается работа всех сотрудников, работающих с этим приложением);
• сложность в обеспечении требуемого качества разрабатываемого продукта, необходимость проведения объемного регрессионного тестирования;
• одна монолитная команда, расширять которую нецелесообразно, так как это не ускорит и не облегчит процесс разработки
• редкие релизы и множество внутренних заказчиков в организации со своими приоритетными задачами, которым приходится выстраиваться в очередь для включения в релиз; растет как негатив со стороны заказчика, так и напряжение со стороны разработки
• невозможность использования различных технологических стеков (а это становится все более важным в гибридных ИТ-средах). Приходится создавать и запускать целое приложение с одними и теми же языками программирования, инструментами и платформами по причине, что «так уже сделано». Да и в самом приложении обновление текущей библиотеки или переход на новую превращается в нетривиальную и высокорисковую задачу;
• сложность в масштабировании.

Проблема монолита данных

Связана с использованием централизованного корпоративного хранилища данных (Enterprise Data Warehouse, EDW)

• Решения с использованием EDW дорогие
• они содержат данные в каноническом формате, который в силу специфических знаний поддерживает и понимает лишь одна команда специалистов, которая обслуживает всех.
• Данные в EDW поступают из различных источников. Команда EDW выверяет их и преобразовывает в канонический формат, который должен удовлетворить потребности различных групп потребителей внутри организации, а команда загружена.
• К тому же данные, преобразованные в некий канонический формат не могут быть удобны всем и всегда. Итог — требуется слишком много времени на выполнение работы с данными.

Паттерны

• Распила монолита

Ускорение монолита

• CQRS
• Отдельный сервис

Антипаттерны

Распределенный монолит

• Набор связанных между собой сервисов, которые необходимо развертывать вместе.
• Присущи недостатки как монолитной, так и микросервисной архитектуры.
• Признаки «монолитного ада»
  • Сложность продукта подавляет разработчиков
  • Разработка идет медленно
  • Путь от коммита до развертывания долог и сложен
  • Масштабирование затруднено
  • Сопровождение и изменение монолитного кода затруднено
  • Продукт привязан к непрерывно устаревающему технологическому стеку
  • В монолите проще провести рефакторинг
  • Микросервисы как распределенный монолит - дорого рефакторить из за интеграций
    • Если преднамеренно не нарушать границы на уровне реализации, то зависимости не появятся
      • Нет зависимостей на уровне сущностей