🪲 Проблемы монолита: разбор на примерах 🪲


🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности (ресурсы): память, ядра процессора и другие.

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

> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям, чтобы выдержать нагрузку.

В архитектуре с сервисами добавить копии можно было бы только на основной сервис, который будут “атаковать” пользователи в ходе рекламной кампании.



🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных реалиях. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.

> В существующем API-методе, в платежной части системы, нужно добавить к JSON-ответу дополнительное поле. Маленькая задача.

В условиях монолита, чтобы выпустить обновление на прод, придётся обновить весь сервер. На время обновления он может быть недоступен.

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


🔺3. Сложность масштабирования команды
Приходя в проект, аналитики, разработчики и тестировщики должны узнать очень много обо всех частях системы, чтобы не вредить ей при развитии и знать, как очередная маленькая функция, может задеть 100 существующих...

Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.

В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.



🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.



🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.

Высококвалифицированные специалисты редко идут в такие проекты, так как им не хочется деградировать и поддерживать легаси код (написанный на старой версии языка, с использованием устаревшего фреймворка, без документации).

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



Это основные проблемы монолитной архитектуры 😔

Но в ней есть и очень много плюсов:
+ легкость в разработке
+ не нужна супер-опытная команда
+ нет проблем в синхронизации данных, которые распределены по разным БД
+ легче устанавливать проект на сервере
Она идеальна для стартапов! 🚀

Монолит - это не плохо. Его можно сделать архитектурно красивым, и с ним будет интересно и приятно работать 🙌 Но всё зависит от опыта программистов, архитекторов и аналитиков, которые участвуют в разработке.

Вопрос про недостатки монолитов важно знать, если предстоит сотрудничество с архитекторами. А также он есть среди подборок теоретических вопросов для собеседований на СА.

Сохраняем этот пост в памяти, чтобы быть готовыми к развернутым ответам 🙂

#АрхитектураGA