⛵️ -> Навигация по главе

Книга начинается с нарратива о техническом директоре компании Food to Go (далее FTGO), Мэри.

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

Основные проблемы:

- Разработка стала медленной и мучительной.

- Доставка изменений является долгим и тяжелым процессом.

- Используются устаревшие технологии.

- Обновление приложения происходит не чаще 1 раза в месяц.

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

Приложение FTGO представляет собой один файл формата Java Web Application Archieve (WAR) или другими словами - монолит.

Как бы не старалась команда разработки, разделяя приложение на модули, проект превратился в антипаттерн "большой комок грязи" (Big Ball of Mud).

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

❗️ Хотя антипаттерн часто наблюдается в монолитных приложениях он может появиться у систем с любой архитектурой.

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

Бизнес логика состоит из модулей - наборов доменных объектов (управление рестораном, управление заказами и т.д.).

Несмотря на наличие модульной структуры, все упаковано в один WAR-файл (пример монолитного стиля).

💡 Монолит - система или приложение, которое упаковывается в единый файл или архив, характеризуемый тесной взаимосвязью компонентов.

На ранних этапах развития приложения существует ряд преимуществ:

1. Простая разработка - все инструменты сосредоточены вокруг создания единого приложения.

2. Легкость изменения - возможность поменять структуру БД или сделать рефакторинг сразу всего проекта.

3. Простое тестирование - возможность написать сквозные тесты, которые могут проверять пользовательский интерфейс, например, при помощи Selenium.

4. Просто развернуть - нужно скопировать WAR-файл на сервер, где установлен Tomcat.

5. Легко масштабировать - запускаем несколько инстансов за балансирощвиком нагрузки.

💡 Монолитный стиль рекомендован на ранних стадиях развития системы.

🛠 Интересный доклад на эту тему с конференции "Highload 2023", где подробно про то, чем монолит может быть лучше микросервисов. Опыт ребят из Авито после того, как им пришлось распиливать монолит и переезжать на новую архитектуру.

Приложениям свойственно вырастать из такой архитектуры:

1. Единая кодовая база требует лишних взаимодействий и координации, так как работа происходит над одним репозиторием.

2. Приложение слишком сложное, чтобы один разработчик мог его понять.

3. Приложение постоянно превращается большой комок грязи.

4. Большое приложение перегружает и замедляет IDE.

5. Сборка занимает много времени.

6. Приложение долго запускается.

7. Долгая и дорогая доставка изменений в промышленную среду. Деплой не чаще одного раза в месяц.

8. Длительное тестирование. Приходится прогонять весь набор тестов (даже при внесении небольших изменений).

9. Трудности с масштабированием: приходится искать компромисс в серверной конфигурации, так как модули составляют единое приложение, а разным модулям могут требоваться разные ресурсы (одним нужно много ОЗУ, другим - ЦПУ).

10. Приложению не хватает локализации неисправности, так как все модули выполняются внутри одного процесса.

11. Может случиться каскадный сбой всех экземпляров в случае проблем.

12. Зависимость на устаревший стек: переписать все с использованием новых технологий - дорого и рисковано.

13. Нет возможности экспериментировать с новыми технологиями.

14. Все вышеописанные проблемы негативно влияют на продуктивность разработчиков.

💡 Приложения вырастают из монолитного стиля: их становится сложно поддерживать и развертывать.

Иллюстрация "монолитного ада". Несколько команд вносит изменения в один репозиторий, развертывание которого в промышленной среде занимает много времени и блокирует других. 

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