Монолит + микросервисы. Совместить несовместимое
Изображение: Shutterstock.ai
Споры в вопросе "что лучше: монолит или микросервисы" настолько масштабны, что могут сравниться разве что с выбором смартфона: IPhone или Android? И если в последнем вопросе не последнюю роль играет привычка, опыт использования как самим пользователем того или иного устройства, так и его окружения, то в выборе между монолитом и микросервисом в основе лежат именно идейно-архитектурные аргументы.
Раньше очень часто можно было услышать что-то вроде "вообще, правильно ... " и далее подставляем любой из вариантов. А когда несколько лет назад, качество, а самое главное, актуальность содержание высшего образования в области информационных технологий вышло на достаточный уровень можно было услышать "в вузе нам говорили ...". Согласитесь, что аргументация неубедительная в обоих случаях, но и убийственных аргументов просто напросто не было. И нет. И смею предположить - не будет.
Также не могу не отметить, что некоторое время назад, мы наблюдали просто сумасшедший интерес к микросервисной архитектуре. Связано это было с массовым хайпом Agile-подходов в ИТ-компаниях. Быстрое тестирование гипотез, scrum-доски и прочая атрибутика вошли в жизнедеятельность компаний данного сектора. У многих компаний подходы прижились и активно используются и по сей день. А микросервисная архитектура является самой близкой к данному подходу.
Ключевые плюсы и минусы
Безусловно, в этом номере журнала уже много говорилось и еще будет говориться о том, какие преимущества и недостатки есть в каждом из подходов. Здесь же я выделю самые важные на мой взгляд, которые дадут нам возможность понять, почему миксовый подход одновременного использования и монолита и микросервисной архитектуры имеет место. Кроме того востребован и эксплуатируется многими компаниями. Ниже выделю ключевые критерии, по которым и будем вести сравнение.
- Скорость создания приложений
Принято считать, что используя микросервисную архитектуру приложения создаются на порядок быстрее. Это и понятно: ведь функционал каждого конкретного микросервиса ограничен, следовательно сделать его проще. А с учетом того, что отсутствуют дополнительные накладные технологические расходы, связанные с включением ранее неиспользуемого или доработкой отсутствующего фукционала монолита (монолит как правило накладывает свои требования к местам и технологиям доработки) прирост в скорости разработки выглядит впечатлающим.
Здесь не могу не отметить, что есть один блок, который разительно отличается в бОльшую сторону при разработке микросервисов - интеграция. Монолит практически не требует доработок в этой части, в то время, как в микросервисе это основа основ. Без входящих и исходящих данных микросервис просто бессмысленен.
- Совокупная стоимость владения
Эта фраза любимая мантра ИТ-директоров. Особенно ее любят говорить руководители, имеющие в своем управлении серьезный ИТ-ландшафт, который обслуживает собственная служба специалистов всех мастей и рангов. Считается, что совокупная стоимость владения ниже там, где используется единый стек технологий. Поэтому если говорить строго, то применяя при разработке микросервисов единые подходы, технологии и методики можно также снизить совокупную стоимость владения. Но на практике с этой фразой более всего сочетается именно монолит. Рассуждения здесь просты: берем одного/двух/пятерых (список можно продолжить) универсальных спецов и они "пилят" вообще все задачи. На лицо экономия. Микросервисы же чаще всего представляют собой огород технологий, наличие которого обосновывается тем, что "есть вот такая-то технология/платформа/фреймворк которая идеально подходит для решения именно этой узкой задачи". Через какое-то время количество РАЗНООБРАЗНЫХ специалистов становится по истине впечатляющим.
- Консистентность и сходимость данных
Здесь мы вновь коснемся вопроса интеграции. Для монолита ситуация более чем понятная: интеграция между модулями отсутствует, данные представлены в одном едином для всей системе месте. Все красиво! Для микросервисов зачастую единого места с данными просто может не быть - они размазаны. И с этой точки зрения успех процесса сбора всех аналитик одной сущности, например, элемента справочника «Материалы» для микросервисов определяется продуманностью и глубиной интеграционных механизмов.
Здесь также стоит отметить, что добавление новой аналитики в монолит все же проще. Как минимум тем, что сделать это нужно в одном месте. Для микросервисов всегда встает вопрос «а в какую именно систему необходимо добавить ту или иную аналитику?». Хотя справедливости ради стоит отметить, что и для монолита очень важно понимать общую архитектуру системы, чтобы добавленные аналитики были доступны для всех подсистем.
И последняя мысль в данном разделе: нередки ситуации, когда из-за проблем с интеграциями в микросервисной архитектуре на период устранения проблем данные в разных системах, что называется начинают «расползаться» и в ряде случаев потребуют ручного внимания для выправления ситуации. Поэтому для нивелирования возможных рисков очень важно определять мастер-справочники - единые и единичные места ввода нормативно-справочной информации в микросервисной архитектуре.
- Быстродействие и отказоустойчивость
Здесь, разумеется, абсолютное чемпионство у микросервисов: автономные или почти автономные функциональные блоки, имеющие свою СУБД, избавленные от множества смежных данных работают, очевидно быстрее. Отказоустойчивость в общем случае выше, чем у монолитов. С одной единственной оговоркой - при правильной архитектуре (чтобы не получилась ситуации когда от падения одного микросервиса веером падают все остальные).
В данном контексте монолит часто именуют синонимом неповоротливости, Ведь зачастую при определенном объеме информации его считают узким горлышком замедляя бизнес-процессы компании.
А как все обстоит на самом деле?
А на самом деле, как водится, все немного не так. Если быть точным, то и так и так. И как в природе нет ничего абсолютного - так и в ИТ-ландшафтах предприятий крайне редко можно встретить одну единую моно-архитектуру.
Если на предприятии присутствует система, агрегирующая многие функции то принято считать, что есть монолит. По оценкам ИТ-менеджмента он, как будто-бы главнее. И даже наличие вокруг такой системы множества микросервисов, которые дополняют ее работу, не берутся в расчет и называются или унаследованными или вспомогательными, хотя на лицо смешанная архитектура. Классический пример таких сателлитов-микросервисов вокруг монолита: оперативный контур (закупки, продажи, склад, логистика), регламентированный учет (бухгалтерский и налоговый) ведутся в монолите, а в микросервисы вынесено построение объемно-календарных планов производства или блок технического обслуживания и ремонтов оборудования. Список таких комбинаций велик и очень часто несет в себе печать смены парадигм в реализации ИТ-функции.
Как же появляются такие миксы? Почти всегда это результат длительных переходных процессов из текущего ИТ-ландшафта в целевой. В 2000-х многие предприятия боролись со старинными наработками своих отделов АСУП, которые по своей сути представляют не что иное как микросервисы! Боролись переходом на монолиты. Но реальность здесь такова, что монолит внедряется дольше, а значит и срок жизни тех старых, как их называли АРМов продолжается в ряде случаев и по сей день. Может быть и обратная ситуация, когда прогрессивный ИТ-руководитель берет курс на полный переход на микросервисную архитектуру и даже успевает реализовать часть плана, но… меняется руководство или уходит сам ИТ-лидер и на предприятии появляется, как его часто называют «полный огород».
Что с этим огородом делать?
На мой взгляд, к любой задаче нужно подходить здраво. Выбор архитектуры - не исключение. Так, "перевнедрять" систему, переводя ее например, ТОЛЬКО на микросервисную архитектуру только потому, что это новое веяние в организации, мне кажется сомнительным. Всегда нужно держать в голове понимание соотношения "эффект для бизнеса - затраты".
Опубликовано 18.04.2024
