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