Монолит
Начнем с традиционной монолитной архитектуры. Представьте себе единую и прочную структуру, в которой все компоненты приложения крепко связаны между собой. Она похожа на большой старинный замок, в стенах которого есть все необходимое.
А, например, в контексте веб-приложений мы говорим о том, что клиентский и серверный код находятся внутри одного проекта. Копнув еще глубже, оказывается, что серверный код – это вообще часть того же процесса.
В чем плюсы монолитного подхода?
Главный плюс монолитов – их простота и легкость разработки. Компоненты монолитной системы тесно связаны, поэтому писать и тестировать такой код сравнительно легко. Вы поддерживаете единую базу кода, и это упрощает понимание общей логики приложения.
К явным достоинствам монолитной архитектуры относятся производительность и эффективность. Поскольку все компоненты выполняются в рамках одного процесса, отпадает нужда в межпроцессном взаимодействии. То есть, более быстрое время выполнения и минимальные временные затраты (мы еще к этому вернемся).
И еще один плюс монолитов – среда совместно используемых данных. У всех компонентов есть прямой доступ к той же базе данных, что позволяет беспрепятственно обмениваться этими данными. Тем самым устраняется необходимость в сложных механизмах синхронизации.
В чем минусы монолитной архитектуры?
Пока что монолиты кажутся на удивление достойным решением. Но, к сожалению, здесь есть свои недочеты. В монолитной архитектуре хватает изъянов.
Один из них – масштабирование. Масштабировать монолиты не так уж просто, ведь все приложение масштабируется как единое целое. В итоге, если дополнительные ресурсы нужны только для определенных компонентов, это может вылиться в их нерациональное использование.
Помните, как выше мы говорили о том, что один из плюсов монолитов – внутренняя производительность? В этом же заключается и их головная боль. Ведь, если подумать, весь монолит потребляет ресурсы сервера, на котором работает (будь то выделенный сервер, виртуальная машина и что-то еще). А если у вас есть сложный продукт с множеством опций, то вся система начнет хромать, когда для работы одной из таких функций потребуются дополнительные ресурсы. Представьте себе ситуацию: пользователь загрузил большой файл, который нужно обработать. И это внезапно сказалось на процессе входа. Пользовательский опыт в данном случае будет просто ужасным.
Более того, монолиты часто «завязаны» на определенном стеке технологий. И добавление новых технологий или фреймворков чревато перепроектированием всего приложения. Такое скудное технологическое разнообразие ограничивает ваши возможности и замедляет дальнее развитие приложения (вы когда-нибудь пробовали поддерживать 10-летнего монолита? Конечно же, там вы не найдете ни намека на код Nest).
Что до развертывания и обслуживания, то монолитные архитектуры – слегка громоздкие. Любые изменения или обновления требуют повторного развертывания всего приложения, и это ведет к увеличению времени простоя и возможным сбоям.
Итого: монолитная архитектура предлагает простоту и эффективность; в ней используется единая база кода и общие данных. Но в монолитах отмечаются явные проблемы с масштабируемостью, развертыванием/обслуживанием, а также ограниченное технологическое разнообразие.
Считать ли монолитную архитектуру – худшим техническим решением из когда-либо придуманных? Конечно же, нет! Для них есть свои области использования.