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

Упрощение облака — это святой Грааль, за которым охотятся ИТ-руководители. Но стремление к этому часто невольно приводит к еще большим сложностям. Это обычная история: организации переходят из онпремисных дата-центров в облако, чтобы добиться простоты, и часто им это удается, но лишь на какое-то время. Они растут и внедряют инновации. Но как только они достигают масштаба, начинается усложнение облака. Все более сложные облачные архитектуры означают рост затрат. Внезапно организации обращают внимание на то, что они обещания с точки зрения совокупной стоимости владения оказываются невыполненными.

Распределение рабочих нагрузок = сложность облака

Распределение рабочих нагрузок по нескольким географическим и облачным регионам, которое может уменьшить задержки для конечных пользователей и снизить риск сбоев, добавляет уровень сложности в облачную инфраструктуру. Грейс Лю, старший вице-президент Seagate по ИТ, отмечает, что такое развертывание сложно организовать и им сложно последовательно управлять, поскольку инфраструктурные инструменты, встроенные в каждую облачную платформу, обычно предназначены для работы в рамках конкретной платформы. «Бизнес-лидеры должны работать с ИТ-лидерами и менеджерами данных, чтобы создать действенную стратегию данных, — говорит она. — Данные — это валюта бизнеса».

Учитывая это, цель состоит в том, чтобы развернуть стратегию и архитектуру, которые обеспечат бизнес-лидерам видимость сразу всех своих данных. Другими словами, CIO должны предоставить возможность беспрепятственно просматривать различные облачные экосистемы. «Начиная думать о развертывании, организации должны поставить себя на место клиентов, — говорит Лю. — Клиенты хотят иметь надежную, высокопроизводительную инфраструктуру, которая поддерживает их бизнес-ценности. Организациям необходимо помнить об этом при разработке технологической цели».

Основные задействованные в облаке стороны

Ключевые участники проекта корпоративной облачной инфраструктуры, на которых необходимо ориентироваться при выработке стратегии, включают архитекторов облака, сети и безопасности, разработчиков приложений, DevOps-руководителей, а также команды оперативного управления и поддержки. Род Штульмюллер, вице-президент Aviatrix по стратегическим отношениям с клиентами и аналитиками, отмечает, что эти заинтересованные стороны традиционно были разрозненными, особенно в крупных корпоративных организациях, и часто не работали в тесном контакте друг с другом. «Проект облачной инфраструктуры предприятия — это возможность объединить эти команды во имя общей цели», — говорит он.

Чтобы создать основу для продуктивного сотрудничества, важно развернуть демонстрационную среду, в которой каждой заинтересованной стороне будет показано, как мультиоблачная архитектура может удовлетворить ее требования. «Используйте обратную связь и привлеките каждую команду к внесению необходимых корректировок, — говорит Штульмюллер. — Дайте им возможность поработать с решением, используя сессии в стиле семинаров. Это позволит всем почувствовать себя комфортно с предлагаемым решением».

Когда упрощение ведет к усложнению

Стремясь к упрощению, ИТ-организации должны понимать, что упрощение архитектур является сложным процессом и может приводить к сбоям. Это означает, что важно определить наиболее подходящий момент, когда это будет полезен для всей организации. «При упрощении не стоит думать только о таких компонентах, как сетевые коммутаторы или СХД, — говорит Лю. — Если вы сосредоточитесь на перемещении или упрощении одного компонента, это может повлечь за собой гораздо больше сложностей. Подумайте об упрощении целых инфраструктурных решений. Сначала согласуйте все на уровне решений или услуг».

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

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

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

Решения для колокации

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

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