Реплатформизация: сложно, но выгодно
TAdviser: Сегодня все говорят про облачную миграцию. Но все ли понимают под этим одно и то же? Что представляет собой миграция в облако?
Николай Бутенко: Миграция в облако бывает двух типов. Первый — когда система сохраняется в том виде, в каком она существовала (в виртуальной среде или на железе). Система целиком перемещается в облако по методике «как есть» (as is). Реализуется это посредством образов системы (снэпшотов), которые и переносятся в инфраструктуру облачного провайдера. Но это немного топорное решение.
Второй тип миграции — реплатформизация. В этом случае исходная инфраструктура преобразуется таким образом, чтобы можно было получить максимальную дополнительную выгоду от перехода в облако. При этом бизнес все чаще старается отказываться от проприетарных решений в пользу открытых технологий, от монолитных приложений — в пользу микросервисной архитектуры. Это позволяет легко разворачивать новые приложения, автоматически горизонтально масштабировать их, сократить время вывода продуктов на рынок (time to market).
TAdviser: Каким образом при реплатформизации преобразуется исходная инфраструктура?
Николай Бутенко: С помощью PaaS-инструментов, предоставляемых облачным провайдером. Например, у заказчика есть база данных, которую он обслуживает и поддерживает самостоятельно. При реплатформизации ее администрирование можно полностью передать облачному провайдеру. Компания просто загружает базу данных в облако и продолжает пользоваться всеми необходимыми функциями, а о таких задачах, как обеспечение отказоустойчивости, масштабирование и обслуживание, больше не думает.
TAdviser: Если сравнивать два типа миграции, какой из них более перспективный и какой чаще встречается на практике?
Николай Бутенко: Реплатформизация — сложный процесс, поскольку требует преобразования приложений, но в долгосрочной перспективе это гораздо более выгодно, ведь на выходе компания получает более отказоустойчивый сервис, пользуется всеми преимуществами PaaS- и SaaS-решений провайдера и может адаптировать архитектуру сервиса под облако (cloud native). Но бизнес, к сожалению, чаще выбирает первый тип миграции.
Реплатформизация — сложный процесс, но в долгосрочной перспективе это более выгодно, чем миграция в облако по методике «как есть»
TAdviser: Это два крайних сценария. А между ними возможны варианты?
Николай Бутенко: Да, конечно. Очень распространен гибридный сценарий. Например, если компания не готова преобразовывать монолитное приложение в микросервисное, но не хочет продолжать обслуживать СУБД, она может использовать преимущества, которые предоставляет облачный провайдер, частично, передав ему управление базой данных. В некоторых случаях это хороший компромиссный вариант: делать полную реплатформизацию затратно, а перенос инфраструктуры «как есть» не обеспечивает необходимого преимущества.
Правильная миграция
TAdviser: О типах миграции поговорили. А какие существуют методы?
Николай Бутенко: Некоторые провайдеры, вероятно, в стремлении заполучить как можно больше клиентов, всячески упрощают процесс перехода в свое облако. Они могут сами осуществить миграцию, предлагают инструменты автоматизации, например специальные агентские решения, которые устанавливаются на виртуальные машины клиента и автоматически переносят систему в облако. Также провайдер может предложить провести аудит инфраструктуры, чтобы определить, какие части можно заменить на облачные сервисы, а какие лучше оставить в исходном виде. Это не плохо, но в конечном итоге может обернуться проблемами. Использовать сервисы одного провайдера удобно, но на самом деле это скрытая привязка к одному вендору (silent vendor lock). В этом случае мигрировать на другую облачную платформу (если возникнет такая потребность) будет очень сложно.
Простота и автоматизм миграции в конечном итоге могут обернуться проблемами
TAdviser: Как этого не допустить?
Николай Бутенко: Во-первых, использовать только базовые облачные сервисы одного провайдера вроде IaaS- и наиболее популярных PaaS-продуктов: СУБД, контейнеризация на Kubernetes. Во-вторых, есть такое понятие — инфраструктура как код (IaC) — это модель декларативного описания инфраструктуры кодом. Как это происходит? Пишутся инструкции, которые говорят, например: «Это приложение должно быть запущено так и с такими параметрами». Существуют специальные инструменты, позволяющие управлять инфраструктурой в облаке как кодом (один из популярных — Terraform). Они дают возможность использовать один и тот же язык описания для разных провайдеров. И если потребуется смена провайдера, компания сможет развернуть точно такую же инфраструктуру на другой облачной платформе за считанные часы или даже минуты — для этого потребуется всего лишь изменить пару строк в коде, заменив адрес (Endpoint) одного провайдера на адрес другого. Все провайдеры предлагают свои инструкции к IaC-инструментам, поскольку многие ими пользуются.
TAdviser: Расскажите об инструментах для осуществления миграции.
Николай Бутенко: Их несколько. Инфраструктуру в облаке можно развернуть с нуля, то есть просто запустить на мощностях облачного провайдера то же количество серверов, которые есть у компании на момент миграции, с теми же параметрами и перенести туда данные. Но это работает только для маленьких сервисов. Большим свойственна сложная топология, что делает перенос таким прямолинейным способом практически неосуществимым.
Для перемещения в облако больших сервисов обычно используют моментальные снимки файловой системы. И если технология исходной инфраструктуры совпадает с технологией облачного провайдера, они просто переносятся в облако, где сразу начинают работать. Для тех случаев, когда технологии разные, что встречается гораздо чаще, существуют конвертеры, преобразующие исходный образ в новый формат.
По сути, это яркие примеры миграции по методике «как есть».
TAdviser: А более продвинутые инструменты есть на рынке?
Николай Бутенко: Конечно. Их предлагают в основном компании, которые раньше занимались технологиями резервного копирования (Veeam, Acronis), и некоторые специализирующиеся на миграции в облака разработчики (например, Hystax Acura).
Образ системы — по сути, ее резервная копия, бэкап — то, что Veeam, Acronis и ряд других компаний в свое время научились делать очень хорошо. Сегодня они предлагают программу-агент, которая умеет создавать копии инфраструктуры для облака.
Специальные инструменты вроде ПО Hystax Acura помогают осуществлять миграцию с разных платформ виртуализации и оборудования в разные облака. При этом есть различные механизмы: агентское решение, устанавливаемое на каждый сервер (виртуальный или физический), агент на гипервизор — «железку», виртуализирующую несколько серверов. Все необходимые конвертации образов выполняются с учетом специфики облачного провайдера.
И последний набор инструментов — самый продвинутый — используется при реплатформизации, то есть при развертывании инфраструктуры в облаке с учетом всех *-aaS-сервисов, которые предлагает облачный провайдер.
TAdviser: Бывают миграционные проекты, требующие особого внимания к аварийному восстановлению (disaster recovery)?
Николай Бутенко: DR-план появляется тогда, когда миграция в облако осуществляется с целью получения запасной площадки. И, надо сказать, это гораздо дешевле, чем строить площадку на базе собственной инфраструктуры, ведь в этом случае обеспечение аварийного восстановления сопряжено с созданием дубликата основной инфраструктуры, что ведет к дополнительному потреблению электроэнергии и увеличению временных затрат ИТ-специалистов.
Инструментарий Mail.ru Cloud Solutions
TAdviser: В арсенале MCS имеется полный набор инструментов для миграции или есть какие-то ограничения в этом плане?
Николай Бутенко: Мы предоставляем нашим клиентам полный набор инструментов и поддерживаем все типы миграции. У нас есть специальные конвертеры и возможность осуществить это в веб-интерфейсе. В партнерстве с Acronis мы предоставляем возможность миграции с помощью резервных копий инфраструктуры. Мы сотрудничаем с Hystax Acura, чтобы наши клиенты могли переносить в облако MCS инфраструктуру с платформ разных провайдеров. Также мы поддерживаем популярные IaC-инструменты, например, Terraform.
TAdviser: А как осуществляется поддержка клиентов, использующих разные сценарии миграции?
Николай Бутенко: Миграция — это индивидуальный процесс. Его отправной точкой всегда является аудит исходной инфраструктуры, потому что не все типы программного обеспечения и оборудования можно виртуализировать. Устаревшее ПО, промышленные базы данных, представляющие собой программно-аппаратные решения, адаптировать под облака бывает или нельзя, или экономически нецелесообразно. В таких случаях инфраструктура обычно лишь частично переносится в облако — проприетарные решения остаются на площадке клиента. Но чаще в инфраструктуре компаний используется стандартная архитектура x86, которая легко виртуализируется.
Мы всегда знакомим клиентов с доступными методами миграции и в случае необходимости помогаем осуществить перенос инфраструктуры в облако.
«Миграция — индивидуальный процесс. Мы всегда знакомим клиентов с доступными методами и при необходимости помогаем осуществить перенос инфраструктуры в облако»
Мультиоблачная стратегия
TAdviser: А что вы можете сказать о мультиоблачном подходе?
Николай Бутенко: Все мы помним, как Роскомнадзор блокировал адреса Amazon. Так что мультиоблачная стратегия, когда используются ресурсы и сервисы не одного облачного провайдера, а нескольких, — самый правильный вариант. Во-первых, нет привязки к одному вендору. Во-вторых, мультиоблако гарантирует быстрое аварийное восстановление. Единственный минус такого подхода — сложность: необходим высокий профессионализм администраторов и разработчиков компании.
TAdviser: Мультиоблако для крупных компаний, работающих и в России, и на Западе, — это необходимость?
Николай Бутенко: Причины, заставляющие бизнес использовать мультиоблачный подход, очень разнообразны и не ограничиваются необходимостью соответствовать требованиям российского законодательства. Есть множетво примеров, когда компании размещали свою инфраструктуру на мощностях популярных облачных провайдеров (как российских, так и зарубежных) из стремления к надежности, быстрому аварийному восстановлению данных, желания отвязаться от одного вендора.
«Причины, заставляющие бизнес использовать мультиоблачный подход, очень разнообразны и не ограничиваются необходимостью соответствовать требованиям российского законодательства»
TAdviser: Экономят ли глобальные компании, выбирая российских поставщиков инфраструктуры?
Николай Бутенко: Несомненно, и я горжусь тем, что мы предоставляем клиентам уровень облачного сервиса, сопоставимый с западными стандартами. Что касается экономии, то значительная часть затрат облачного провайдера приходится на электроэнергию, в России она дешевая, да и труд квалифицированных специалистов, как ни крути, стоит меньше, чем в Европе. Отсюда и более низкие цены на виртуальные ресурсы. За меньшие деньги мы предоставляем сервисы с тем же уровнем SLA. В первую очередь международные компании интересуют базовые PaaS- и IaaS-сервисы, потому что у «большой тройки» глобальных облачных провайдеров — Amazon Web Services, Google Cloud и Microsoft Azure — очень много проприетарных решений, которые в России не предоставляет никто.
TAdviser: Какие проблемы возникают при интеграции систем в случае мультиоблачного подхода?
Николай Бутенко: При создании полноценного мультиоблачного приложения мы зачастую ограничены в выборе предоставляемых сервисов. Мы обязаны использовать базовые решения, которые легко переносить из облака в облако. В противном случае мы получим две разнородные облачные структуры, поддержка которых будет настоящим кошмаром.
Когда мы говорим об интеграции систем в мультиоблаке, как правило, речь идет о реализации Direct Connect, то есть обмена файлами по защищенным выделенным каналам (в противовес взаимодействию через интернет). И, конечно, мы должны сделать обязательную репликацию данных, это важнейшая составляющая работы по запуску мультиоблака.
TAdviser: У MCS есть техническое решение для интеграции с облаком Amazon. Что это за инструмент?
Николай Бутенко: Объясню на примере. Возьмем глобального игрока из индустрии игр, бизнес которого вырос в России и здесь локализован. У него есть желание предоставлять свои игровые сервисы за рубежом. Мы знаем, что любая задержка раздражает игроков. Чтобы она была минимальной даже для пользователей из Северной Америки или Австралии, серверы должны находиться в соответствующих регионах. Поэтому мы предложили решение, автоматизирующее федерацию Kubernetes — оно позволяет автоматически направлять часть нагрузки в соответствующий регион. Запустив федеративный кластер Kubernetes в Amazon, вы получаете возможность пользоваться им по всему миру. Соответственно, в России компания — клиент Amazon может запустить мощности на ресурсах MCS с наименьшими задержками. И наоборот: если компании — клиенту MCS нужно захостить часть мощностей в Северной Америке, можно запустить мощности на ресурсах Amazon. Единая консоль управления позволит часть этой нагрузки запустить в Северной Америке.
TAdviser: Возникает ли необходимость в интеграции с платформой Яндекса?
Николай Бутенко: Есть клиенты, которые хотят строить мультиоблако на базе двух российских облачных провайдеров — Mail.ru Cloud Solutions и «Яндекса.Облака». И им очень повезло — и мы, и «Яндекс» используем гипервизоры KVM, хотя платформы виртуализации — разные. По этой причине обеспечение согласованности при запуске базовых сервисов, настройка репликаций данных не вызывают у клиентов затруднений. Вместе с тем бизнес, естественно, хотел бы иметь более серьезный уровень интеграции: было бы удобно запускаться частично здесь, частично там, используя единую панель управления. Но сейчас такой возможности нет: мы их очень уважаем, но мы конкуренты.
TAdviser: А что можете сказать об интеграции с платформами других облачных провайдеров?
Николай Бутенко: Облачная тусовка в России довольно маленькая, это очень дружное сообщество. Люди знают друг друга в лицо и по имени. И когда нужно решить какие-то задачи интеграции с платформой другого облачного провайдера, договориться очень легко — при условии, что это взаимовыгодно, конечно. Технические задачи возникают, но все они решаемы — это именно задачи, а не проблемы.
Мониторинг облачной инфраструктуры
TAdviser: Мониторинг облачной инфраструктуры — актуальная задача?
Николай Бутенко: Мониторинг и аудит логов — то, что интересует абсолютно все компании. Спрос на эти опции очень высокий: все хотят знать, что происходит с их сервисами, почему и когда. Без возможностей мониторинга и аудита логов сегодня сложно представить себе хороший сервис.
В облаке MCS есть легковесный мониторинг виртуальных машин, сервисы встроенного мониторинга на базе Prometheus. И сейчас мы работаем над полноценным сервисом мониторинга, который по желанию клиента будет хранить информацию в течение длительного периода времени.
«Спрос на мониторинг облачной инфраструктуры очень высокий: все хотят знать, что происходит с их сервисами, почему и когда»
TAdviser: А как организуется сквозной мониторинг мультиоблачной инфраструктуры?
Николай Бутенко: В мультиоблаке сквозной мониторинг настроить не так уж сложно. Мы предоставляем собственные системы мониторинга на базе популярных решений — Zabbix и Prometheus, можем поставить наши агентские программы на инфраструктуру клиента.
Будущее облачных технологий
TAdviser: Поговорим о гибридном облаке. Что это такое? В чем специфика гибридной конфигурации?
Николай Бутенко: Гибридное облако — это облако, в котором часть ресурсов запущена в частном облаке, а в случае необходимости есть возможность разместить часть ресурсов в публичном облаке. Гибридная конфигурация — самая сложная в технологическом отношении. Для создания настоящего гибридного облака частное облако компании должно быть построено практически на тех же технологиях, что и публичное облако вендора. При такой конфигурации остро стоит вопрос безопасности, должен быть реализован сквозной биллинг — это очень непростые задачи. Автоматическое создание проектов и ряд других функций требуют передачи административных прав на публичное облако, а это означает, что публичное облако должно пожертвовать частью своего суверенитета в пользу гибридного. С технологической точки зрения выполнение всех обязательств по поддержанию SLA — очень большая работа. Такие проекты встречаются крайне редко.
TAdviser: В каком направлении идет развитие архитектуры платформы Mail.ru Cloud Solutions?
Если говорить о продуктовой стратегии, то наши дорожные карты формируются на основании обратной связи от клиентов и рыночных реалий. Мы идем по пути расширения PaaS-линейки: начиная с мониторинга и аудита и заканчивая бессерверными вычислениями и большими данными. Будущее — за платформенными сервисами, они упрощают администрирование и внедрение облачных технологий.
Также мы активно обрастаем партнерами. Компаниям удобно публиковать в нашем облаке готовые приложения по модели SaaS. Нашими партнерами становятся компании — эксперты в разных областях, как правило, лидеры рынка. Например, Arenadata (аналитика больших данных), Acronis (резервное копирование).
TAdviser: А как же инфраструктурные сервисы?
Николай Бутенко: Сегодня IaaS — уже базовая история, которой никого не удивишь. Такие сервисы есть у всех.
TAdviser: Какие кейсы облачной миграции, реализованные в этом году, вы оцениваете как знаковые и почему?
Николай Бутенко: В нашей практике был один занимательный случай, когда клиента внезапно попросили съехать с облака. Он в панике пришел к нам — и мы буквально за полтора дня перенесли в наше облако все его сервисы. Это была без преувеличения молниеносная миграция. К знаковым можно отнести и очень крупный проект компании «УРУС». Сейчас реализуется проект с применением всех наших инструментов автоматической миграции в облако на основе Hystax Acura. Миграция идет по методике «как есть» с добавлением некоторых дополнительных сервисов, облегчающих работу компании, есть планы по реплатформизации после перехода в облако.
TAdviser: Какой первый вопрос чаще всего задают клиенты, планирующие облачную миграцию?
Николай Бутенко: «Сколько это стоит?».
TAdviser: Что вы им отвечаете?
Николай Бутенко: У нас есть онлайн-калькулятор, который позволяет узнать стоимость миграции для каждого конкретного случая. Для крупных клиентов условия определяются в индивидуальном порядке.
«Будущее — за быстроразвивающейся, гибкой, масштабируемой инфраструктурой, и обеспечить все это способна только облачная модель»
TAdviser: Что вы посоветуете тем, кто в данный момент раздумывает, стоит ли осуществлять миграцию в облако?
Николай Бутенко: Я не просто рекомендую — я почти требую: мигрируйте в облако! Все очень просто: если вы хотите, чтобы завтра ваш бизнес был конкурентоспособен, вы обязаны двигаться в сторону микросервисной, совместимой с облаком архитектуры. Выбор конфигурации — частное облако, публичное, мультиоблако или гибридное — не так важен. Будущее — за быстроразвивающейся, гибкой, масштабируемой инфраструктурой, и обеспечить все это способна только облачная модель.
Облачные технологии стали де-факто стандартом размещения сервисов и инфраструктуры. Если вы технический директор, миграция в облако — это первое, чем вы должны заняться. Это позволит повысить отказоустойчивость, масштабируемость, сократить время вывода продуктов на рынок и сэкономить: в 99% случаев облачная инфраструктура дешевле традиционной.
Автор текста: TAdviser
вернуться на главную
