Комментарии 11
Архитектура чего-л. по определению - это структура, композиция. Об архитектуре вообще можно говорить только при наличии больше одной составляющей. Поэтому "монолитная архитектура" - это оксюморон. Отсюда уже можно заключить, что понятие монолита почти никогда, за исключением каких-то экстремальных случаев, не относится к системе в целом. Вы не можете построить по SOA систему на все времена - как только появляется дополнительная вариативность в бизнесе, у вас тут же появляются монолитные компоненты, которые раньше были вполне себе сервисами (логическими компонентами, решающими определенную бизнес-задачу), а теперь стали монолитами, которые нужно пилить на сервисы дальше (или можно обнести костылями, то есть решениями по обходу ограничений, что уже будет являться этими вашими спагетти, комами грязи и прочими мнемоническими понятиями для описания частных антипаттернов). Вот в этом уже заключается Архитектура, как искусство - соблюдение баланса между ростом энтропии системы и сложностью реализации актуальных задач, реализующаяся со своими историческими стилями в их диалектическом развитии.
Любой монолит всегда является частью какой-либо системы — здесь сложно найти исключения. Любое монолитное здание представляет собой элемент системы и на определённом уровне является частью города.
Однако, чтобы эффективно и с пользой рассуждать о том, что такое система в целом, необходимо учитывать точку зрения наблюдателя и соответствующий уровень рассмотрения. Например, для тестировщика, который пишет поведенческие тесты, опираясь исключительно на API монолитного бэкенда, сам этот монолит может (и должен) восприниматься как система в целом.
Монолитная архитектура, несомненно, является оксюмороном, с чем я полностью согласен.
Темпоральность же только добавляет динамики: монолитный бэкенд, существующий сегодня, то есть его текущая версия, завтра может быть разделён на части и наоборот. Как уже отмечалось, структуры программных решений могут быть весьма изменчивыми во времени.
Монолитная архитектура не является оксюмороном, потому что она не сочетает взаимоисключающие понятия. Это просто описание структуры системы, где все компоненты тесно связаны.
Если взять к примеру здание - как монолит, т.е. нечто цельное, которое не может быть разобрано без потери этой целостности. Но по сути это относится к способу производства такого здания, архитектура все равно предполагает наличие частей, структуры, принцип соединения и т.п. архитектурные качества, т.е. в здании возведенном по монолитной технологии есть несущие конструкции, есть входы и выходы - тоже что и в сборной хрущевке.
Пролистал до перечня достоинств и недостатков монолита. Много воды.
Достоинства согласен в принципе.
Недостатки:
Монолит сложнее синхронизировать поставку обновлений разных модулей, что негативно сказывается на сроках вывода на рынок (TTM);
Давайте развернем.
Синхронизация обновлений модулей это неплохо сформулировано.
Монолит имеет средства статической проверки исполнения контрактов кода, в том числе контрактов между модулями. Имеет простую систему юнит и интеграционных тестов.
В противовес распределенная система имеет иные методы управления стыковкой модулей: версионность, в том числе одновременно несколько версий, постепенный перенес нагрузки на новую версию и ещё много деталей. При экстренной замене сервис можно отключить, оставив копиться задачи в очереди. И быстро запустить новый.
функциональность разных модулей может иметь разную критичность для бизнеса, а при сбое монолит выходит из строя целиком
Что выходит из строя: монолит или его инстанс? Перенаправили на другой сервер, первый рестартанул и бежим дальше.
модули с разными требованиями к нагрузке конкурируют за ресурсы и доступ к базе данных;
Да. СУБД не имеют управления приоритетами запросов. А в монолите сложнее определить нагрузку на ЦП и ОЗУ от конкретного модуля: даже если разделить на DLL нельзя узнать сколько потребляет каждая.
модули могут обрабатывать данные с разной степенью конфиденциальности, и разграничение доступа становится всё более сложной задачей;
Да. Платежный сервис всегда отдельно. Но таких частей, требующих кардинальной изоляции обычно мало.
Я бы выделил, что монолит требует меньше человеко часов разработки одной и той же фичи чем распределенные системы. Но только до определенного размера кода и количества разработчиков.
Монолит подходит для водопадной системы управления продуктом, с вертикальной иерархией при согласовании изменений. Микросервисы хороши для нескольких команд (от 5 команд по 10 человек) с горизонтальными связями между командами.
В комментарии я увидел внутреннюю дискуссию относительно достоинств и недостатков монолита и обеспечении развиваемости решения. Хочу уточнить, что в статье не рассматривались достоинства и недостатки монолита. Я лишь выделил ключевое свойство монолита — простоту, которая может быть преимуществом в одних условиях, но в других это преимущество может быть утрачено. Иными словами, монолит на старте всегда проще, чем любые альтернативы, но со временем простота может быть утрачена, и могут возникнуть противоречия.
В комментарии также прозвучал вопрос: "Что выходит из строя: монолит или его инстанс?" В статье речь шла об утрате работоспособности отдельного инстанса или всего кластера монолитного бэкенда, то есть о полной утрате работоспособности бэкенда.
На практике мне доводилось наблюдать падения/утрату работоспособности кластеров монолитов. Например, кластеров NiFi и Confluence, когда под нагрузкой происходит переполнение стека на одном из узлов, что приводит к каскадному отказу всего кластера.
Вообще предмет "конструирование программ" преподают на профильных специальностях.
Эта статья предназначена главным образом для новичков в разработке ПО, многие из которых не имеют профильного образования, а также для людей из смежных областей, проявляющих интерес к данной теме.
Понимание монолита: изделие и конструкция в программном обеспечении