Монолиты — это загадочные сущности по определению. В тысячах глобальных организаций монолитные приложения часто стоят отдельно, бок о бок, подобно своим собратьям из Стоунхенджа — архитектурным шедеврам прошлого, вызывающим благоговение и таинственность. Но в отличие от своих доисторических аналогов, монолитные приложения являются неотъемлемой частью современной структуры бизнеса и ключевыми участниками всех критически важных бизнес-процессов, от бэк-офиса до цепочки поставок, от обслуживания клиентов до коммерческого взаимодействия и т. д., пишет на портале The New Stack Боб Куиллин, директор по экосистемам компании vFunction.

Хотя монолиты продолжают вносить огромный вклад в бизнес, модернизация этих приложений является постоянным источником разочарования и боли. Многие организации просто сдались, а другие в качестве временной меры перевели все монолиты в облако с помощью рехостинга или реплатформинга — старого «lift and shift». Но на дворе 2022 г., и появилась надежда, что новые технологии и новые подходы разрушат мифы, окружающие монолиты.

Миф № 1. Модернизация монолита — это пустое дело

У каждого облачного провайдера, нативной облачной платформы и системного интегратора есть модель, которая включает практически все способы модернизации. Изначально индустрия начинала с пяти «R» модернизации: rehost (рехостинг), refactor, (refactoring), re-architect (перепроектирование), rebuild (переделка) или replace (замена). По мере того, как модернизация развивалась и в нее вовлекалось все больше консультантов, увеличивалось и количество «R», включая replatform (реплатформинг), rewrite (переписывание), retain (сохранение) и retire (вывод из эксплуатации). Это сбивает с толку, потому что практика модернизации стала больше искусством, чем наукой. В процессе модернизации монолита задействовано слишком мало данных, математики и автоматизации. Существуют книги и лучшие практики, а также множество консультантов и архитекторов решений, готовых дать совет и помочь. Это отлично, но, как правило, они либо сосредоточены на подходах DIY («сделай сам»), либо на дорогостоящих и рискованных аутсорсинговых проектах.

Но не все так плохо. Сейчас идет новая волна развития инструментальных средств, прикладного искусственного интеллекта и автоматизации, которые позволяют преодолеть разрыв между вариантами «сделай все сам» и «отдай все на аутсорсинг». В основе этих подходов лежит реальный архитектурный анализ монолита, не только базовых компонентов платформы, которые необходимо перенести на новые версии, но и самой бизнес-логики. Бизнес-логика — это мясо приложения, и именно здесь архитекторы могут начать определять предметные области, которые могут привести к более четким микросервисным доменно-ориентированным проектам. Как минимум, это будут более независимые минисервисы или просто обычные сервисы, которые работают с более высокой степенью эксклюзивности.

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

Миф № 2. Миграция монолита в облако = модернизация

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

Этот миф быстро развеивается: теперь большинству организаций ясно, что монолит в облаке имеет большинство тех же проблем, что и онпремис — низкая скорость разработки, недостаточная масштабируемость, сложность в обслуживании и низкая устойчивость. Многие называют этот этап «сожалением о переносе» или «угрызениями совести по поводу миграции», поскольку затраты начинают расти, а преимущества облака все еще недосягаемы. Чтобы развеять этот миф, миграцию необходимо рассматривать и планировать в контексте более масштабной, стратегической модернизации — миграция хороша до тех пор, пока она является ступенькой к полностью модернизированному монолиту. Модернизация монолита позволяет ему использовать все преимущества нативной облачной архитектуры — от контейнеров и микросервисов до Kubernetes и бессерверных вычислений. Добавьте сюда преимущества использования общих политик и платформ CI/CD, безопасности и DevSecOps, и ваш бизнес-кейс быстро встанет на свое место, что ведет нас к мифу № 3.

Миф № 3. Построение точного бизнес-кейса модернизации приложений невозможно

Для большинства организаций самой сложной частью модернизации приложений является построение точного бизнес-кейса для проектов модернизации. Мы рассмотрели один из недостающих элементов для решения этой проблемы в мифе № 1: отсутствие основанного на данных обсуждения между архитекторами, которые прогнозируют время и усилия, и бизнес-лидерами, утверждающими бюджет и ресурсы. Отсутствие общего языка и основы для измерения приводит к двустороннему разрушению доверия между лидерством и менеджментом. Чтобы разорвать этот замкнутый круг, для начала необходимы данные и измерения.

Начните с аналитического измерения сложности монолита и риска, связанного с его изменением. Чтобы понять сложность, необходимо сначала определить кластеры зависимостей, которые указывают, где домены являются очевидными и, следовательно, где могут быть выделены микросервисы. Затем сложность может быть рассчитана по степени запутанности зависимостей классов между собой, которая снижает уровень модульности кода. Риск может быть измерен длиной цепочек зависимостей, которая определяет, насколько вероятно, что изменение в одной части приложения повлияет на несвязанную часть приложения ниже по течению. Все эти показатели могут быть сведены в общую оценку технического долга, которая показывает, сколько в настоящее время тратится на долги по сравнению с инновациями, и, таким образом, окупаемость инвестиций и TCO бизнес-кейса проекта модернизации. С такой сильной количественной позиции бизнес-профессионалам гораздо легче прийти к согласию, что приводит нас к разрушению мифа № 4.

Миф № 4. Все монолиты созданы одинаковыми

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

Для приложений, которые все еще характеризуются жизнеспособным вкладом в бизнес, необходимо полностью оценить сложность и риск, связанный с их модернизацией (см. миф № 3), чтобы разработать оптимальный план и, следовательно, более точный бизнес-кейс. Рассчитав сложность, риск и результирующий технический долг по критически важным для бизнеса монолитам, вы сможете перевести менее сложные из них в более быстрые проекты модернизации, используя для ускорения средства автоматизации на базе ИИ. Более сложные монолиты — часто называемые «мегалитами» — потребуют больше времени и должны следовать более итеративному подходу к рефакторингу для выборочного выделения одного или двух микросервисов за раз с использованием паттерна Strangler для переключения управления с монолита на новые сервисы. Эти монолитные приложения могут существовать где угодно, даже в облаке, так что переходим к мифу № 5.

Миф № 5. Монолиты — это онпремисная проблема

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

Те же методология оценки на основе данных и подход к определению приоритетов, описанные выше, возможно даже в большей степени применимы к этим монолитам в облаке. Почему? Оценка на основе данных, модернизация с помощью ИИ и рефакторинг после миграции — это ключевые компетенции, необходимые всем архитекторам решений и ПО. Монолит в облаке уже очень близок к тому, чтобы полностью реализовать свое модернизационное предназначение. Контейнеры, Kubernetes, DevOps, бессерверные и сеточные сервисы будут готовы к запуску на облачном провайдере, как только завершится процесс рефакторинга монолита. Просто распутайте этот монолит; см. миф № 6.

Миф № 6: Зависимости монолита невозможно распутать

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

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

Миф № 7. Модернизация монолита занимает вечность

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

В течение последнего десятилетия модернизация приложений была передовой практикой, требующей большого количества людей, широкого обучения и культурных и организационных преобразований. Эти методы являются критически важными навыками, но отсутствие средств автоматизации и поддержки замедляло процесс из-за нехватки навыков и усталости от неудач. Однако появились новые инструменты, которые охватывают эти методологии и поднимают их на новый уровень с помощью ИИ и автоматизации. Следующий шаг — развертывание методологии непрерывной модернизации, которая подключается к конвейеру CI/CD, обнаруживает и устраняет технический долг на протяжении всего жизненного цикла приложения.