О мифологии миграции монолита в облака

Около десяти лет назад микросервисы получили первое признание. (Однако есть альтернативное мнение, что микросервисам уже пятнадцать лет). С тех пор масса фирм воспользовалась услугами облачных провайдеров и перенесла свои сервисы к ним. А некоторые из них даже успели разочароваться в облачных технологиях и вернулись к традиционной схеме монолита (или почти к ней, см. например [TB]). 

Эта статья - не попытка уговорить вас на перенос вашего монолита в облако или отговорить от этого. Это попытка описать мифы по поводу такого переноса. 

Но вначале нам необходимо договориться о том, что же это такое - монолит.

Развивая идею из публикации [SN], я предлагаю ввести пять частичных метрик для измерения монолитности той или иной программной системы:

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

2. Монолитность исполняемых артефактов. Это количество исполняемых артефактов. Например, это может быть количество ваших JAR-файлов. При этом иногда, в зависимости от особенностей вашей системы, вместо собственно JAR-файлов следует считать папку с “основным” JAR-файлом и вспомогательными файлами используемых библиотек и конфигураций.

3. Монолитность времени исполнения (run time). Один исполняемый артефакт может использоваться у вас многократно (параллельно), с балансировкой каким-либо балансёром или диспетчером.

4. Монолитность хранения данных. Эта величина измеряется количеством разных систем хранения ваших данных. Хранит ваше приложение данные в одной базе данных или в нескольких? Если система использует файловую систему в качестве хранилища данных - в скольки файлах и папках она это делает?

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

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

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

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

Миф №1: Всё или ничего

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

На самом деле это не так. Архитектурный паттерн, известный под именами  “Призма”( см. [PR]), схожий с “Canary deployments”[CD]  и A/B Testing, позволяет разрабатывать новые микросервисы постепенно, независимо от основного приложения и “сбоку”  от него. Идея паттерна показана на рисунке внизу.  

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

Если ваша система общается с внешним миром с помощью HTTP-протокола, оба треугольника могут быть реализованы в виде одного простого proxy-сервера. Различные Service Mesh инструменты типа Istio предоставляю такую возможность на уровне конфигурации.

Первая (красная) призма направляет все входные данные на монолит, дублируя при этом данные “интересные” заново имплементированному сервису и посылая дублированные данные на него.  Вторая призма перехватывает выходные данные вашего монолита, дублирует результаты запланированного к замещению сервиса и посылает дубликаты на сравнение в Comparator. Ну а Comparator сравнивает результаты нового варианта с результатами монолита. 

Таким образом, монолит работает как и раньше (синие элементы на рисунке). 

Когда вы убедитесь, что в течении определённого времени новый сервис работает корректно и стабильно, вы можете перенастроить обе призмы и перестать использовать в монолите старую реализацию сервиса. 

Миф №2: Просто расщепим на части и докенизируем

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

Нередко миграция монолита в облако представляется как простое “расщепление” монолита на несколько частей и перенос каждой части сначала в Docker/Kubernetes, а возможно потом - в одну из облачных сред типа AWS или Azure.

Увы, в большинстве случае так просто решить проблему не получается. 

Если ваш монолит используется давно и интенсивно, он наверняка “оброс” вторичными автоматическими и ручными процессами, которые иногда для бизнеса могут быть ценнее процессов самого монолита. Как правило, эти процессы пользуются конечными или промежуточными данными, созданными монолитом либо наоборот, в определённых ситуациях процессы вашего монолита требуют ручного вмешательства или помощи внешних процессов. 

Поэтому, прежде чем приступать к миграции монолита, надо тщательно инвентаризировать его окружение. Типичными “неочевидными” stockholderes   являются сотрудники или системы следующих отделов или направлений:

1. Финансы (например, Data Warehouse)

2. Reports

3. Рекламации

4. Ручные обрывы процессов в определённых ситуациях

5. Коррекция неверных данных

6. Evaluation (Периодическая оценка ситуации)

7. Настройка системы

8. Audit

9. Workarounds

Способы удовлетворения потребностей этих групп должны быть учтены при подготовке плана миграции.

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

Расщепление монолита на части означает, как правило, не только замену API общения компонент монолита между собой, но и смену парадигмы их коммуникации. На практике это оборачивается переходом на event driven механизм коммуникации. 

Не вдаваясь в детали, отметим пунктиром, над чем в этом случае следует подумать и что постараться сделать:

1. Использование паттерна SAGA (см. [SA])при реализации распределённых транзакций.

2. Использование паттерна QCRS (см. [QC])при работе с распределёнными данными.

3. Использование идемпотентных функций (см. [IF]), позволяющих при возникновении проблем просто вызывать их заново без опасения за состояние сохранённых данных).

Миф №3: Переносить надо только функциональность, всё остальное предоставит провайдер

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

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

1. Мониторинг

2. Аудит 

3. Desaster  Recovery

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

Миф №4: Облачные сервисы очень дёшевы

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

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

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

Практика показывает, что со временем “центр тяжести” перемещается на оплату именно этих, а не базовых сервисов.

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

Поэтому, мигрируя свои сервисы в облако, надо постоянно помнить о vendor lock-in и проектировать облачную архитектуру так, чтобы при необходимости иметь возможность сменить провайдера. 

Миф №5: Микросервисы должны быть маленькими

То, что микросервисы должны быть маленькими, явствует из самого их названия, не правда ли? Поэтому при миграции в облака монолит надо разбить на большое число маленьких частей, разве не так? Примеры ландшафтов со многими сотнями и даже тысячами микросервисов, как например в банке Monzo ( см. [MB]), вроде бы также говорят в пользу такого подхода.

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

К счастью, отрасль уже накопила достаточное понимание проблемы и выработала конструктивные рекомендации по вопросу расщепления монолита на микросервисы. Детали вы найдёте в работах [HS], [ST], [HS1]. Здесь же короткий перечень основных критериев, когда такое расщепление возможно стоит делать:

1. Выделять в отдельный сервис функциональность с объективно повышенной вероятностью ошибок в run time.

2. Реализовывать компоненты с заведомо разным жизненным циклом в разных сервисах.

3. Разделять на сервисы компоненты с заведомо разными ожидаемыми частотами внесения изменений и обновлений.

4. Выделять в отдельный сервис функциональность, требующую повышенной скалируемости.

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

А иногда различные микросервисы появляются на свет просто из-за организационных причин (необходимость реализовать их разными командами).

Миф №6: Затраты на миграцию монолита непредсказуемы

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

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

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

Миф №7: Раз все так делают, значит так можно

Сервис мега-провайдера типа AWS или Azure отличается низкой латентностью, высокой надёжностью и доступностью по всему миру за счёт их собственных Data Centers. Неудивительно, что многие фирмы и государственные службы пользуются их услугами.

При этом использующие эти сервисы фирмы на вопрос о соблюдении правил защиты данных потребителей нередко отвечают: “Ну если все так делают, значит это легально”. 

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

Увы, это не соответствует действительности. Все мега-провайдеры соблюдают законы США, в том числе - CLOUD Act [CA], позволяющий американским службам без судебного решения потребовать от провайдера любые данные. А это противоречит многим национальным и европейским законам о защите данных их граждан.

“Но это в теории, на практике-то ничего неприятного не происходит?”, возможно спросите вы. Нет, происходит. Например, в Германии уже рассматривались случаи наложения штрафов на образовательные учреждения и отдельных преподавателей за использование облачных продуктов типа Microsoft Office 365, Zoom и т.п.( см. [ MO]). В апреле 2021 года немецкая служба защиты приватных данных (Datenschutz-Aufsichtsbehörde) потребовала от многочисленных немецких фирм обоснования хранения данных у американских облачных провайдеров в связи с решением Европейского Суда по вопросу соглашения „Privacy Shield“ (см. [DF]).

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

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

Что же касается американских спецслужб - я очень советую вспомнить про Сноудена, а ещё лучше прочитать (если не читали) его книгу [ES]. Лично меня в ней поразили две вещи.

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

Вторым поразившим меня в этой книге был эпизод с вербовкой абсолютно невиновного молодого человека, который в будущем мог занять в иерархии своей страны интересующую спецслужбы позицию. Сноуден в деталях рассказывает о попытках “подставить” этого человека под судебную ответственность. Знание некоторых деталей его биографии, его привязанностей и слабостей им в этом очень помогло. Собственно, в этом нет ничего нового. Мы все много раз видели это в кино про КГБ, ЦРУ и т.д. Но воспоминания Сноудена как участника операции показывают, что это всё не выдумки. Как мы видим, спецслужбы иногда охотятся и за абсолютно невиновными людьми. Хотите вы с вашим сервисом в этом участвовать (осознанно или неосознанно), особенно, если этого можно не делать?

Наверное нет. Так что же делать?

Самое главное - будьте честны перед своими пользователями. Перед тем как доверить вам свои данные, человек должен осознать, чем он рискуют. Расскажите ему (ей) об этом, перед тем как начать сотрудничество.

Постарайтесь сами обойтись без излишних приватных данных. Возможно, ваш бизнес может обойтись без обратной связи с некоторыми категориями пользователей через Email или телефон. Если ваш бизнес ориентирован на профессионалов, вы можете поддерживать в учётных записях (accounts) только логин, пароль и серию контрольных вопросов. 

Хорошим решением является подбор провайдера авторизации и финансовых услуг в стране ваших интересов. Этот вариант технически и организационно сложнее “лобового”, но освобождает вас от многих рисков. 

Ну и как самый крайний вариант - не используйте специализированные фичи мега-провайдеров, а используйте решения на базе открытых решений типа Docker/Kubernetes/Kafka, что позволит вам при необходимости развернуть бизнес в облаках локальных провайдеров интересующей вас страны.

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

Вместо заключения

Изложенное в этой статье не претендует на роль истины в последней инстанции. Процесс миграции монолитов в облака находится в полном разгаре. Накопленный опыт миграции неплохо обобщён и осмыслен в книге [MM]. 

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

Ссылки и литература

Иллюстрации автора.