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

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

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

В отчете Flexera «2021 State of the Cloud» говорится, что 92% предприятий имеют мультиоблачную стратегию. При этом речь идет как о тех, кто уже начал свой путь, так и о тех, кто только вступает в стадию планирования. Так что вы не одиноки: управление сложностью различных облачных провайдеров — это основное поле битвы для предприятий.

Почему мы используем мультиоблака

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

Возможность выбора лучшей в своем классе технологии. AWS может иметь лучшую систему анализа данных для вашей системы управления запасами. Однако у Google может быть лучшая платформа искусственного интеллекта для ваших нужд, а у Microsoft может быть система SaaS, которую вы хотите использовать. И так далее.

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

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

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

Это означает, что ваша конфигурация будет иметь преимущества с одними облаками, но не с другими. Учитывая, что сумма счета может превысить 500 тыс. долл. в год и скорее всего будет увеличиваться по мере роста бизнеса, это серьезные соображения. Поэтому важно проконсультироваться с поставщиком облачных услуг по поводу конкретных политик и цен.

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

Устранение зависимости от одного поставщика. Многие указывают на мультиоблачность как на способ избежать вендорлока (привязки к одному поставщику). Хотя использование услуг одного поставщика, безусловно, имеет свои преимущества, но если вы пишете свои приложения, чтобы использовать некий нативный облачный API, предоставляемый только одним из ваших облачных провайдеров, то вы практически попадаете в зависимость от него. Мультиоблачность мало что дает для решения этой проблемы, кроме возможности привязки к нескольким поставщикам, но ограничения остаются теми же, если не хуже.

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

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

Новые передовые мультиоблачные практики

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

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

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

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

Вот некоторые из лучших практик, которые чаще всего способствуют успеху мультиоблака:

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

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

При развертывании одного облака вы ограничиваете количество технологий, которые можно использовать, но большинство из них специально разработаны для совместной работы. При мультиоблачном развертывании количество используемых облаков нелинейно умножается на число различных доступных технологий. Например, в одном облаке может быть пять различных собственных решений для хранения данных (например, блочное, объектное, файловое и т. д.), но при использовании трех общедоступных облаков в составе мультиоблака их может быть до 30.

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

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

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

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

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

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

3. Учитывайте то, что находится между облаками, а не только то, что в них. В мультиоблачности важно не то, что работает внутри каждого облака, по крайней мере, концептуально; важно то, что работает между ними. Сюда входят все общие сервисы, которые должны охватывать все мультиоблако, включая безопасность, управление, операции и т. д. Сюда входят все сервисы, которые должны быть одинаковыми для облаков и которые будут работать как «облачно-агностические» или «кросс-облачные» технологии.

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

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

Освоение мультиоблаков методом проб и ошибок

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

Есть ли хорошие новости? Начинают появляться некоторые общие лучшие практики. Важно, чтобы вы как можно больше узнали о пробах и ошибках тех, кто пришел до вас, а затем выработали собственные конкретные решения. Те, кто последуют лучшим практикам, упомянутым в этой статье, с большей вероятностью добьются успеха в мультиоблачной среде.