В мультиоблаках не выжить с узкой специализацией
Рост популярности нового подхода в передовых мировых компаниях объясняется очевидными преимуществами: исчезает зависимость от одного поставщика ИТ-ресурсов, снижается риск потери данных, повышается гибкость в выборе наиболее эффективного провайдера для узкоспециализированных задач. Однако за это приходится расплачиваться пересмотром управленческих и технологических подходов. Эволюция аутсорсинга сервисов (SaaS), платформ (PaaS) и инфраструктуры (IaaS), заключающаяся в интеграции решений от различных провайдеров, ставит перед ИТ новые задачи, объединенные общей целью — функционирование пула облаков как единого целого.
Этот тренд появится на российском рынке в течение 2–3 лет. Он плотно связан с развитием крупных облачных провайдеров, таких как «Яндекс.Облако», «Деловое облако» от «МегаФон», Huawei Cloud Russia и другие. Динамика заметна: «Яндекс» последовательно развивает экосистему PaaS и привлекает партнеров для предоставления приложений из облака (SaaS). Huawei Cloud уже собрала под своим крылом рабочий пул IaaS-сервисов и идет дальше — развивает PaaS-подход.
Все это говорит о том, что при создании стратегии развития платформ и приложений уже сейчас нужно держать в голове вызовы ближайших лет. И к этой трансформации нужно готовиться в нескольких направлениях: архитектурном, отвечающим за уровень приложений, организационном и технологическом.
Адаптируем приложения к облачной инфраструктуре
Боб Виолино (Bob Violino) в материале »7 секретов успеха мультиоблачной стратегии» рекомендует провести полную инвентаризацию существующих приложений. То есть отобрать приложения, которые целесообразно мигрировать в облако и оценить, насколько они приспособлены для работы в нем (cloud-native). Для оценки в качестве чек-листа можно использовать критерии Twelve-factor apps или более расширенном варианте Кевина Хоффмана (Kevin Hoffman) — Beyond the Twelve-Factor App.
Переносить в облако приложение, построенное по устаревшим принципам, сложно и часто нецелесообразно, а cloud-native приложений не так много, особенно в старых областях. Если приложение не соответствует этим принципам, но требует частых изменений конфигурации (например, обновлений кода, масштабирования вычислительных ресурсов и т.д.), можно автоматизировать управление инфраструктурой с помощью одного из фреймворков автоматизации управления вычислительной инфраструктурой, например Ansible, SaltStack, Chef и т.д.
Cloud-native приложения по своей природе платформонезависимые. Чтобы обеспечить требуемую кроссплатформенность сегодня активно используются технологии контейнеризации. Виртуализация операционной системы с помощью контейнера и «запаковка» туда приложения гарантирует работоспособность на любой совместимой вычислительной платформе. Контейнеры объединяют в себе все необходимые файлы приложения и зависимого ПО в виде компоновочного блока. Если образ с бинарным кодом и конфигурацией запустится в тестовой среде, он точно будет работать и локально, и в частном облаке, и у гиперскейлера. Существует множество программных продуктов для реализации такого подхода, среди них: Docker, rkt, PouchContainer. Для эффективного разворачивания приложений и применения централизованных политик управления используются платформы оркестрации контейнеров. Сегодня наибольшей известностью пользуются Kubernetes и решения на его основе (например, OpenShift, Docker Swarm и Apache Mesos).
Снижаем риски за счет централизации управления
Без адаптации процессов управления ИТ с учетом использования сразу нескольких публичных облаков, гибкость и доступность неограниченного объема ресурсов может привести как к неконтролируемому росту расходов, так и к рискам потери данных. Потребуется еще какое-то время, пока будет наработан опыт использования решений корпоративного уровня для единого управления пулом облаков. На повестке — решить задачи по автоматизации процессов представления и сворачивания ресурсов на нескольких платформах, наладить мониторинг доступности и работоспособности приложений и ресурсов, а также обеспечить безопасность и аварийное восстановление систем. Фактически, централизация снимает большинство опасений, связанных с переходом на мультиоблачность. Опросы Gartner подтверждают наличие этих ключевых проблем.
Связываем облака в единую среду
В мультиоблаке могут работать несколько типов пользователей: как минимум это внутренние и аутсорс-разработчики, а также внешние пользователи системы. Само мультиоблако может включать в себя частные и публичные облака, на которых разворачиваются тестовые и продуктивные среды. В связи с этим одна из сложнейших задач — сетевая связность и доступность приложений. Например, в российских компаниях часто встает проблема динамического выделения непересекающихся диапазонов внутренних адресов для неизвестного заранее количества подсетей. Также нужно обеспечить защиту хотя бы на сетевом уровне — и все в автоматическом режиме. На помощь приходят технологии виртуализации, в частности, — программно-определяемые сети (SDN и SDWAN). Использование SDN позволяет менять схемы маршрутизации внутри ЦОД и облаков в зависимости от имеющихся потоков данных в различных участках в сети, которые в свою очередь зависят от профиля нагрузки работающих поверх этой сети прикладных систем. Решения SDWAN позволяют решать проблемы связанности между облаками, ЦОД и площадками заказчика. На основании нашего опыта обе эти технологии достигли достаточного уровня зрелости для применения в организациях самого разного масштаба.
Организуем доступность данных
Планируя то, как будет реализована доступность данных в мультиоблаке, необходимо проанализировать способы использования данных и самих облаков. Если создается классический резервный ЦОД, то целесообразно реплицировать данные на уровне СХД или платформы виртуализации. То есть организовать гибридную систему хранения, включающую в себя как подключаемые облака, так и собственные сервера компании.
Для тестовых сред, где допустимо использование данных с отставанием, возможно реплицировать резервные копии СУБД. В зависимости от объемов данных для этой задачи подходит как собственный инструментарий СУБД, так и самостоятельные системы резервного копирования.
Обеспечить сохранность данных можно также за счет их репликации на уровне СУБД. Так как данные, хранящиеся на СХД, все равно обрабатываются на уровне СУБД, их асинхронную репликацию можно обеспечить с этого уровня. При таком подходе нужно искать баланс между производительностью и сложностью логики записи приложения.
Вопросы доступности данных и сервисов тесно связаны с соотношением двух важных показателей: RPO (recovery point objective) — допустимая потеря данных и RTO (recovery time objective) — допустимое время восстановления данных. Причем под вторым подразумевается время, необходимое для обеспечения доступности данных для пользователя, то есть и восстановление работоспособности приложений. Эти целевые показатели ставит перед ИТ бизнес-заказчик, исходя из анализа возможных финансовых потерь. Внедрение и поддержка выбранного решения должны обеспечивать безубыточность относительно риска возможных потерь данных.
Концепция мультиоблачности, вместе с ощутимыми выгодами, несет в себе новые вызовы для ИТ-профессионалов. Очевидно, что технологии и подходы, используемые для того, чтобы на них ответить, окажут существенное влияние на отрасль уже в ближайшем будущем. Но уже сейчас становится ясно: мультиоблачность невозможна в рамках узкой специализации, она требует от ИТ глобального подхода и широких компетенций менеджмента.
Александр Краснов,
заместитель руководителя дирекции вычислительных комплексов, сервиса и аутсорсинга
«Инфосистемы Джет»
Полный текст статьи читайте на CNews
