Что такое монолитная архитектура программного обеспечения

Обновлено: 19.05.2024

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

Монолитное ядро

По сути дела, операционная система – это обычная программа, поэтому было бы логично и организовать ее так же, как устроено большинство программ, то есть составить из процедур и функций. В этом случае компоненты операционной системы являются не самостоятельными модулями, а составными частями одной большой программы. Такая структура операционной системы называется монолитным ядром (monolithic kernel). Монолитное ядро представляет собой набор процедур, каждая из которых может вызвать каждую. Все процедуры работают в привилегированном режиме. Таким образом, монолитное ядро – это такая схема операционной системы , при которой все ее компоненты являются составными частями одной программы, используют общие структуры данных и взаимодействуют друг с другом путем непосредственного вызова процедур. Для монолитной операционной системы ядро совпадает со всей системой.

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

Монолитное ядро – старейший способ организации операционных систем . Примером систем с монолитным ядром является большинство Unix-систем.

Даже в монолитных системах можно выделить некоторую структуру. Как в бетонной глыбе можно различить вкрапления щебенки, так и в монолитном ядре выделяются вкрапления сервисных процедур, соответствующих системным вызовам . Сервисные процедуры выполняются в привилегированном режиме, тогда как пользовательские программы – в непривилегированном. Для перехода с одного уровня привилегий на другой иногда может использоваться главная сервисная программа, определяющая, какой именно системный вызов был сделан, корректность входных данных для этого вызова и передающая управление соответствующей сервисной процедуре с переходом в привилегированный режим работы. Иногда выделяют также набор программных утилит, которые помогают выполнять сервисные процедуры.

Многоуровневые системы (Layered systems)

Продолжая структуризацию, можно разбить всю вычислительную систему на ряд более мелких уровней с хорошо определенными связями между ними, так чтобы объекты уровня N могли вызывать только объекты уровня N-1. Нижним уровнем в таких системах обычно является hardware, верхним уровнем – интерфейс пользователя. Чем ниже уровень, тем более привилегированные команды и действия может выполнять модуль, находящийся на этом уровне. Впервые такой подход был применен при создании системы THE (Technishe Hogeschool Eindhoven) Дейкстрой (Dijkstra) и его студентами в 1968 г. Эта система имела следующие уровни:

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

Виртуальные машины

В начале лекции мы говорили о взгляде на операционную систему как на виртуальную машину , когда пользователю нет необходимости знать детали внутреннего устройства компьютера. Он работает с файлами, а не с магнитными головками и двигателем; он работает с огромной виртуальной, а не ограниченной реальной оперативной памятью; его мало волнует, единственный он на машине пользователь или нет. Рассмотрим несколько иной подход. Пусть операционная система реализует виртуальную машину для каждого пользователя, но не упрощая ему жизнь, а, наоборот, усложняя. Каждая такая виртуальная машина предстает перед пользователем как голое железо – копия всего hardware в вычислительной системе, включая процессор , привилегированные и непривилегированные команды, устройства ввода-вывода, прерывания и т.д. И он остается с этим железом один на один. При попытке обратиться к такому виртуальному железу на уровне привилегированных команд в действительности происходит системный вызов реальной операционной системы , которая и производит все необходимые действия. Такой подход позволяет каждому пользователю загрузить свою операционную систему на виртуальную машину и делать с ней все, что душа пожелает.

Первой реальной системой такого рода была система CP/CMS, или VM/370, как ее называют сейчас, для семейства машин IBM/370.

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

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

Современная тенденция в разработке операционных систем состоит в перенесении значительной части системного кода на уровень пользователя и одновременной минимизации ядра. Речь идет о подходе к построению ядра, называемом микроядерной архитектурой ( microkernel architecture) операционной системы , когда большинство ее составляющих являются самостоятельными программами. В этом случае взаимодействие между ними обеспечивает специальный модуль ядра, называемый микроядром. Микроядро работает в привилегированном режиме и обеспечивает взаимодействие между программами, планирование использования процессора , первичную обработку прерываний , операции ввода-вывода и базовое управление памятью.

Основное достоинство микроядерной архитектуры – высокая степень модульности ядра операционной системы . Это существенно упрощает добавление в него новых компонентов. В микроядерной операционной системе можно, не прерывая ее работы, загружать и выгружать новые драйверы, файловые системы и т. д. Существенно упрощается процесс отладки компонентов ядра, так как новая версия драйвера может загружаться без перезапуска всей операционной системы . Компоненты ядра операционной системы ничем принципиально не отличаются от пользовательских программ, поэтому для их отладки можно применять обычные средства. Микроядерная архитектура повышает надежность системы, поскольку ошибка на уровне непривилегированной программы менее опасна, чем отказ на уровне режима ядра.

Смешанные системы

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

Другим примером смешанного подхода может служить возможность запуска операционной системы с монолитным ядром под управлением микроядра. Так устроены 4.4BSD и MkLinux, основанные на микроядре Mach . Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов. Все остальные функции, в том числе взаимодействие с прикладными программами, осуществляется монолитным ядром . Данный подход сформировался в результате попыток использовать преимущества микроядерной архитектуры , сохраняя по возможности хорошо отлаженный код монолитного ядра .

Таким образом, Windows NT можно с полным правом назвать гибридной операционной системой .

Массовый переход с монолитной на микросервисную архитектуру (MSA, Micro Service Architecture) связан с развитием облачных сервисов и необходимостью обеспечить максимально оперативное обновление и модернизацию сервисов в соответствии с меняющимися бизнес-задачами. В статье, подготовленной для TAdviser, журналист Олег Нечай рассказывает о ключевых особенностях, преимуществах, инструментах и сложностях микросервисного подхода.

Содержание

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

При этом в сообществе программистов всё чаще звучат голоса скептиков, не считающих микросервисы чем-то принципиально новым. По их мнению, это просто реализация сервис-ориентированной архитектуры (SOA) на более низком уровне. Как бы то ни было, микросервисная архитектура имеет очевидные преимущества, особенно в сфере Agile-разработки и развёртывания сложных приложений корпоративного уровня.

Микросервисы как естественная архитектура облачных приложений

По состоянию на 2021 год микросервисная архитектура считается наиболее естественным подходом для разработки облачных приложений. Таковые состоят из множества слабо связанных и независимо разрабатываемых мелких модулей — сервисов. Для этих сервисов, как правило, характерны три свойства:

С точки зрения бизнеса и чисто организационных задач, преимущества микросервисов сводятся к трём основным:

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

Микросервисы, монолитная архитектура и SOA

Чтобы уточнить отличия микросервисов от других архитектур, их чаще всего сравнивают с монолитной архитектурой и сервис-ориентированной архитектурой (service-oriented architecture, SOA). Микросервисное приложение состоит из множества мелких независимых и слабо связанных между собой сервисов, в то время как в монолите все его компоненты тесно взаимосвязаны и работают как единый сервис. Помимо прочего, это значит, что если какой-то один процесс в приложении с монолитной архитектурой становится более востребованным, приходится масштабировать всё приложение в целом. Сбой в каком-то одном процессе может поставить под угрозу всю систему. Наконец, такая сложность ограничивает возможности модернизации и затрудняет внедрение новых идей.

Монолитная архитектура (Monolithic) отличается тесной взаимосвязью между компонентами, включая бизнес-логику (Business Logic) и слой доступа к данным (Data Access Layer), и выступает как единый сервис. В микросервисной архитектуре (Microservices) клиент через общий пользовательский интерфейс (UI) получает доступ к отдельным слабо связанным между собой микросервисам (Microservice). Источник: Red Hat, Inc

Отличия микросервисов от SOA не столь очевидны. Можно пойти по сложному пути и перечислить множество технических деталей, в том числе связанных с ролью сервисной шины предприятия (ESB), но можно поступить проще и оценить уровни, на которые распространяются эти архитектуры. Если SOA — это архитектура уровня предприятия, призванная стандартизировать взаимодействие всех служб, то микросервисы относятся к какому-то одному конкретному приложению.

Микросервисы, менеджеры и разработчики

Редкий случай: микросервисная архитектура практически так же популярна среди руководителей проектов, как и среди самих разработчиков. Причина в том, что микросервисы отлично вписываются в схемы, по которым многие менеджеры структурируют задачи и управляют командами разработчиков. Проще говоря, микросервисная архитектура лучше всего отражает привычные процессы управления.

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

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

Микросервисы и DevOps

Методология DevOps (от англ. development и operations; набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга) часто рассматривается как одно из важнейших и непременных достоинств микросервисов, что неудивительно, поскольку речь идёт о частом развёртывании небольших сервисов. Более того, именно следование принципам DevOps делает микросервисы успешной архитектурой. В отличие от монолитной архитектуры, микросервисная — это сложная распределённая система с множеством независимых элементов, которая требует оперативного взаимодействия между разработчиками и пользователями, частого обновления и максимального уровня автоматизации. А это именно то, в чём заключается суть концепции DevOps.

Ключевые технологии и инструменты

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

Прежде всего, речь идёт о Docker [3] — ПО для развертывания и управления приложениями на основе контейнеризации — модели вычислений, наиболее тесно ассоциируемой с микросервисами. Поскольку индивидуальные контейнеры для приложений не обладают всеми атрибутами полноценной операционной системы, они меньше и легче по объёму, чем обычные виртуальные машины. Благодаря этому они запускаются и отключаются быстрее, и тем самым идеально подходят для небольших и лёгких микросервисов.

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

Бессерверные вычисления — стратегия, доводящая до логического завершения некоторые ключевые особенности облачных и микросервисных технологий. При её реализации исполнительный блок представляет собой даже не просто маленький сервис, а лишь функцию, которая часто выражается в нескольких строчках кода. Грань, отделяющая бессерверную функцию от микросервиса, довольно условна, поэтому функция обычно рассматривается как ещё более мелкий процесс, чем микросервис.

Микросервисы и облачные сервисы

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

Недостатки микросервисной архитектуры

Разумеется, не бывает идеальных решений, и у микросервисов тоже есть слабые места. Главный недостаток микросервисов кроется в самой их природе: распределённая система со множеством независимых элементов сложнее как в организационном, так и в архитектурном плане. Усложняется управление командами разработки и развёртывания, и здесь не обойтись без методологий Agile и DevOps. Распределённый доступ к сервисам означает увеличение сетевых задержек и потенциальных сбоев, с чем можно бороться путём асинхронности и сокращения числа вызовов.

Не стоит забывать и о необходимости обеспечивать согласованность приложения: из-за децентрализации и модульности возможно возникновение неконсистентности данных, также приводящее к сбоям и недоступности приложения в целом. В этом случае стоит искать компромиссы между доступностью сервисов и консистентностью.

Из-за этих и других подобных ограничений специалисты не рекомендуют [6] переходить на микросервисы просто в погоне за модой: бизнес должен располагать грамотной и подготовленной командой разработчиков и администраторов, а также достаточной инфраструктурой. Кроме того, эксперты не советуют использовать эту архитектуру без облачных технологий, а также практик Agile и DevOps.

В практике UppLabs мы столкнулись с очень интересным техническим кейсом. У нас был проект с конкретной целью — увеличить производительность приложения при помощи миграции с монолитной системы на новую инфраструктуру микросервисов. Для решения этой задачи наша команда решила применить новый подход.

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

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

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

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

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

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

Основные характеристики микросервисной архитектуры:

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

Зачем нужна миграция?

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

Коммерческое программное обеспечение может быть дороже и сложнее в развертывании по сравнению с программным обеспечением с открытым исходным кодом. Микросервис из 10 000 строк вряд ли так сильно позволит задействовать базовую платформу.

68% компаний уже используют микросервисы в производстве и разработке;
36% крупных компаний, 50% средних компаний, 44% малых компаний используют микросервисы в производстве и разработке;
26% компаний изучают микросервисы, но еще не начали их внедрять; , сообщили о 13-кратном увеличении частоты выпусков программного обеспечения.

Трудности при переходе на микросервисы

При переходе с монолитных приложений на микросервисную архитектуру интеграция сталкивается с некоторыми проблемами. Обычно это означает, что разработчикам нужно восстанавливать прежние версии с нуля. Вот почему весь процесс может привести к таким сложностям:

траты времени и денег;
нет требований или фактического состояния, только код;
возникновение технических вопросов: о технологиях, подходах, применении на практике.

Монолит VS микросервисы

Главный вопрос: почему люди хотят заменить монолитную архитектуру на микросервисы? Статистика показывает, что между монолитными и микросервисными системами существует значительная разница в производительности, которая достигает 79,2%.

Монолит	Микросервисы
Типичное монолитное приложение состоит из базы данных, клиентского пользовательского интерфейса и серверного приложения.	Микросервисы в основном получили свое название из-за того, что сервисы здесь меньше, чем в монолитной среде.
Все части программного обеспечения объединены, так что можно управлять всеми его функциями в одном месте.	В микросервисной архитектуре сервисы, которые связаны слабо, взаимодействуют между собой и таким образом выполняют свои бизнес-задачи.
Компоненты монолитного программного обеспечения взаимосвязаны и взаимозависимы.	Здесь существует много единиц развертывания. Каждый сервис развертывается независимо друг от друга.
Монолитные приложения обеспечивают быструю связь между программными компонентами благодаря общему коду и памяти.	Меньшие размеры сервисов помогают, когда дело доходит до времени компиляции, выполнения и времени запуска тестов.

Плюсы и минусы монолита

Преимущества монолита	Недостатки монолита
При монолитной архитектуре вы можете быстро начать реализацию своей бизнес-логики, вместо того чтобы тратить время и размышлять о взаимодействии между процессами.	Медленный процесс разработки: нужно время для каждой функции. Поскольку компоненты работают вместе, их также необходимо менять вместе.
Проще реализовать сквозные (E2E) тесты.	Масштабирование может быть проблематичным. Когда одна часть системы требует дополнительных ресурсов, в монолитной архитектуре масштабировать отдельные части системы довольно сложно.
Когда дело доходит до операций, монолит проще развернуть и масштабировать.	В монолите практически отсутствует изоляция. Если в модуле возникнет проблема или ошибка, она может замедлить или разрушить все приложение.
Монолит — самый быстрый и относительно недорогой способ создания небольшой системы.	Отключение или обновление исходной базы может быть трудным, поскольку необходимо сделать это сразу и для всех частей вашей системы.
Монолитная архитектура удобна для небольших команд.	По мере того, как растет кодовая база, качество ухудшается, а IDE (Integrated development environment — интегрированная среда разработки) постепенно перегружается.
В монолитной архитектуре есть много инструментов, которые вы можете интегрировать, чтобы упростить разработку.	_

Плюсы и минусы микросервисов

Реальный кейс UppLabs

Давайте рассмотрим наш пример, поскольку он отлично иллюстрирует ситуацию, когда команде пришлось перестроить монолитную архитектуру на микросервисы для решения таких проблем:

На первых этапах визуальная часть проекта выглядела довольно просто:

Визуализация на первых этапах проекта

Два решения

Команда UppLabs предложила клиенту несколько решений:

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

Заказчик одобрил второе решение, и команда приступила к его реализации. Во время первого мозгового штурма команда UppLabs проанализировала существующее приложение. Помимо монолита, в проекте клиента были проблемы со структурой кода, поэтому его пришлось переписывать с самого начала.

Наша команда решила внедрить логику в микросервис, создав API Public Getaway, благодаря которому можно было легко общаться обеим сторонам — клиентам существующих проектов и бизнес-клиентам.

API Public Getaway

Сегодня команда UppLabs реализовала план, поэтому у него такая структура:

Масштабирование

Мы уже определили следующий план действий для клиента по масштабированию приложения. Собираемся разработать:

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

Этапы реализации могут занять около года, но с постоянными релизами на каждом этапе.

Результат

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

Сейчас мы работаем над реализацией плана.

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Размышления о разработке программного обеспечения и информационных систем

То, что действительно важно, но чему нигде не учат

Монолитная архитектура - это схема построения информационной системы, из которой крайне сложно выделить автономные блоки (модули или подсистемы) из-за их сильной связанности кода. Не путайте со случаем, когда система поставляется в виде одного единого компонента-приложения: этот случай просто про развёртывание, и сегодня я его обсуждать не буду.

К сожалению, столкнулся с ситуацией, где коллеги на полном серьёзе решили отстаивать именно монолитную архитектуру системы. Ох. Ну, поговорим о монолите ещё раз.

Начнём с основ. Для чего мы делаем информационные системы? Мы их делаем, чтобы они могли добавлять определённую ценность активам заказчика. Либо сами системы могут становиться такими активами.

Хорошо, но мало. Допустим, что на момент внедрения система стала ценным активом, но как долго она будет сохранять свою ценность? Надо бы добавить в нашу цель динамику. Итого, мы делаем наши системы, чтобы они становились ценными активами и сохраняли свою ценность долгое время. В пределе, система должна увеличивать свою ценность со временем, т.е. иметь потенциал не только для модернизации, но и для функционального развития.

Но мне могут возразить. Всё, что описано выше - это с точки зрения заказчика. С точки зрения исполнителя разрабатываемая система - продукт, который приносит деньги. Чем дешевле будет продукт, тем больше денег останется в прибыли от цены контракта. Конечная цели исполнителя - прибыль от разработки системы. Так ведь?

Не совсем. Точнее, совсем не так. Не от разработки. А от всего жизненного цикла системы. Полная прибыль исполнителя достигается при следующих условиях:

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

И как же монолитная архитектура помогает нам максимизировать прибыль и осчастливить заказчика на долгие времена?

Монолит - самый быстрый и дешёвый способ реализации системы. При нескольких условиях: (1) требования не должны меняться, (2) команда должна оставаться единой всё время разработки, (3) никакого сопровождения системы не предполагается. Иными словами, монолит - замечательный подход для быстрой апробации технических решений и для создания небольших утилит.

Ещё монолит используют для обучения джунов-разработчиков на разных курсах, но я бы таких "преподавателей" близко бы к джунам не пускал. К сожалению, в ПО, создаваемом разными компаниями для собственных нужд, часто встречаются монолитные решения. Пример такой паутины связей я представил на заглавном рисунке (диаграмма связей получена для реального проекта в MS VisualStudio). Происходит это как раз из-за того, что такие вот "преподаватели" учат джунов и непрофессиональных разработчиков делать такие вот "системы".

Во всех остальных случаях, кроме перечисленных в предпоследнем абзаце выше, монолит - это зло злющее.

С точки зрения заказчика даже в случае, если система будет создана и внедрена в срок и будет соответствовать всем его желаниям, наслаждаться её использованием он будет недолго. Ибо (1) предметная область меняется, как сама жизнь, (2) в компании всегда присутствует текучка кадров, хотя бы из-за перемещения вверх по карьерной лестнице, и новые кадры не понимают, что делать с запутанным кодом системы, и (3) сопровождать монолитную систему становится очень дорого, проще сделать новую.

С точки зрения исполнителя. Ну сами смотрите. Допустим, что исполнитель сделал монолит и внедрил его. Он празднует "победу": сэкономил 1 млн рублей. Но гарантия по договору разработки длится год, а система уже на следующей неделе дала сбой: качество кода оказалось так себе, потому как протестировать монолит невозможно. И в течение следующего года исполнитель постепенно растратил всю свою "прибыль" на костыли к монолиту. Именно "костыли", потому как починить монолит нет возможности в рамках скудного бюджета и небольшого времени.

После года мытарств исполнитель оценил, во что ему выльется сопровождение этой системы в будущем - и отказался от участия в конкурсе на сопровождение. Имеем чистую недополученную прибыль, т.е. сплошной убыток.

Затем и в конкурс по развитию системы исполнитель первичного контракта не пошёл. Кому охота рефакторингом монолита за свой счёт заниматься? Снова недополученная прибыль.

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

Новые контракты недовольный заказчик не даёт, поминая старое. В деловом сообществе качество системы - притча во языцех: какая уж тут реклама, какие новые контракты? Забыть бы тот контракт, но пристал он к бренду, как банный лист. И вот владельцы бизнеса закрывают свою компанию и создают новую. Сплошные убытки. И всё из-за одного монолита.

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

Читайте также: