Принятие стратегии гибридного облака и успешное внедрение гибридной среды — это две совершенно разные вещи. Генеральный директор Coralogix Ариэль Ассараф делится с порталом InformationWeek стратегией, состоящей из шести шагов, которая позволит провести миграцию приложений поэтапно, чтобы стабилизировать работу оставшейся части локальной инфраструктуры.

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

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

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

1. Какого провайдера публичного облака выбрать?

Вместе с ростом индустрии гибридного облака растет и разнообразие вариантов поставщиков и решений. Естественно, AWS, GCP и Azure имеют предложения, обладающие собственными преимуществами и возможностями для улучшения. Существуют также менее жесткие платформы, такие как OpenShift, которые дают возможность перемещать приложения и связанные с ними данные между частным и публичным облаком без изменения структуры приложения («lift and shift»). Разнообразие вариантов на рынке дает вам свободу выбора того провайдера, который соответствует требованиям вашей организации.

2. Является ли приложение, которое нужно перенести в облако, новым или унаследованным?

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

3. Является ли приложение, которое требуется перенести в облако, контейнерным?

Контейнеры — это основа для создания архитектуры на базе микросервисов в облаке. Kubernetes — крупнейший Open Source-инструмент оркестровки контейнеров, и основные поставщики облачных услуг и другие технологические гиганты создали сервисы на его основе. Обязательно выделите достаточно времени, чтобы ознакомиться с инструментами оркестровки и мониторинга вашего облачного провайдера.

4. Является ли приложение, подлежащее переносу, масштабируемым?

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

5. Какие услуги поддержки нужны приложению в облаке?

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

6. Готов ли персонал к гибридному облаку?

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

Выводы

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