Как мигрировать в российские облака? 10 рекомендаций

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

При выработке стратегии перехода в облако необходимо помнить, что отнюдь не любая технология может быть перенесена в облако. Тому есть много причин, но основные, на наш взгляд, две. Во-первых, – весьма ограниченное число операционных систем, которые представлены у провайдеров публичных облачных сервисов: как правило, это различные версии Windows Server и Linux Server. В настоящий момент отсутствует возможность переноса в облака сервисов и решений, построенных на операционных системах AIX, OS/400, z/OS и ряде других. Чтобы такие приложения заработали в облачной среде, их необходимо переписать под доступные ОС. Это большая и ресурсоемкая задача. Во-вторых, предприятия используют значительное количество «монолитных» приложений, написанных для среды Windows, которые невозможно перенести в облака. 

Есть и другие важные отличия облачных технологий от так называемых корпоративных, или enterprise-технологий. Прежде всего, правильно примененный enterprise-подход обеспечивает сохранность данных, их доступность и пр. на уровне архитектуры. Многие корпоративные приложения построены таким образом, что они масштабируются вертикально. Это означает, что они увеличивают свою производительность за счет наращивания производительности своих узлов. Облачные же приложения и технологии масштабируются горизонтально – они потенциально могут повысить свою производительность при увеличении числа узлов. 

Кроме того, если корпоративные приложения и технологии следуют концепции ACID (Atomicity, Consistency, Isolation, Durability), то облачные – концепции BASE (Basically Available, Soft state, Eventual consistency). Из этого следует, что при создании облачных систем разработчик должен сам отслеживать сохранение целостности данных, их доступность, независимость (если требуется) и отказоустойчивость – и обеспечивать программу соответствующими механизмами. Это кардинально меняет подход к требованиям и разработке приложений для облаков, и именно отсюда берут начало микросервисные архитектуры, event driven-архитектуры, data domain.

Еще одна важная составляющая облачных технологий – это механизм использования данных/ресурсов, так называемая мультиарендность (multitenancy). В классической (корпоративной) системе имеется ограниченное число «обитателей», и известно, кто они. В облаке же сегодня ресурсом может пользоваться кто-то один, а завтра пользователей уже десятки тысяч. Это требует особых механизмов разграничения прав и защиты. Но следует понимать, что ответственность за защиту данных от несанкционированного доступа, кражи, порчи и т. д. лежит на пользователе облачных услуг (он же разработчик приложения). Если он не реализовал соответствующие механизмы или неправильно их настроил, никто за него этого не сделает. Это еще одно кардинальное отличие облачных технологий от корпоративных, где упор изначально делается на доступность, целостность и безопасность данных.

Конечно, серьезные облачные провайдеры обязаны предоставлять защиту данных как услугу (в стандартном пакете или дополнительно). В подобный пакет должны входить такие технологии и средства обеспечения комплексной информационной безопасности, как шифрование данных, защита от различного рода посягательств и несанкционированного доступа, защита данных от потерь (например, резервирование у другого оператора или в другой локации, создание резервных копий на других носителях и в других географических зонах). К сожалению, российские провайдеры в этом отношении менее развиты, чем их ведущие зарубежные коллеги. Если зарубежные операторы могут работать в 5–10 различных географических зонах, то российские, как правило, не более чем в трех. Это еще один довод в пользу необходимости скорейшего создания федеральной сети ЦОДов, охватывающей большое число регионов.

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

Важно, чтобы перед началом работ компания ответила себе на ряд вопросов: какие цели она преследует миграцией в облако, какие именно процессы будут улучшены и какие станут менее затратными. Не секрет, что многих подкупает «демонстративная» дешевизна публичных облачных ресурсов – цены могут очень низкими, но выставляться за час или даже за минуту. И многие думают: «О, как дешево!». На самом деле нет. Чтобы верно оценить реальную стоимость, необходимо провести сайзинг, учесть, что систему в облаке все равно необходимо обслуживать и для этого необходимы недешевые специалисты. А поскольку облака – это отдельный пласт технологий, «традиционные» специалисты, которые уже работают в организации, не всегда способны или готовы правильно понять, точно выбрать и безотказно сопровождать облачные решения.

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

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

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

Итак, для миграции в облако мы рекомендуем придерживаться следующего плана действий:

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!

<< Предыдущая статья   Вернуться к содержанию   Следующая статья >>