Для начала рассмотрим классический в каком-то смысле вариант монолитной архитектуры. Монолитная архитектура предполагает, что все компоненты системы прочно связаны в одно приложение, которое разрабатывается, тестируется и развертывается как единое целое.
Главная особенность монолитов — это единство. Единство кодовой базы, процессов развертывания, компонентов. То есть все функции приложения собраны в одном репозитории, и это сильно упрощает управление кодом и его версиями. Приложение разворачивается целиком, это упрощает процесс деплоя и обновления, а компоненты системы управляются централизованно, что упрощает мониторинг и контроль.
Преимущества монолитной архитектуктуры:
1. Простота разработки: все компоненты находятся в одном месте и тесно связаны, поэтому разработчикам не нужно учитывать межсервисное взаимодействие. Писать и тестировать код проще.
2. Высокая производительность: так как все компоненты находятся в одном месте и в рамках одного процесса, отсутствие сетевых вызовов между компонентами системы позволяет достичь высокой производительности.
3. Единое управление: легче управлять и контролировать одну кодовую базу, чем множество разрозненных сервисов.
4. Понятная структура: для новых разработчиков проще вникнуть в проект, так как вся логика находится в одном месте.
Звучит уже убедительно, и монолиты кажутся по всем параметрам подходящим решением, неправда ли? К сожалению, недостатков тоже хватает:
1. Масштабирование: масштабировать монолиты — сложно. И нерационально. Так как все наши компоненты связаны воедино, то, когда требуются дополнительные ресурсы лишь для одной части — увеличить придется мощность всего приложения. Это может привести к совершенно нерациональному использованию мощностей.
2. Ненадежность: ошибка в одном компоненте может привести к сбою всей системы. В этом, пожалуй, состоит главная «боль».
3. Трудности обновления: любые изменения требуют полной пересборки и развертывания приложения, что может привести к простою.