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

Автор: Кевин Кейси, автор The Enterprisers Project

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

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

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

Как только эти основы заложены, возникает несколько важных вопросов и проблем. Перемещение рабочих нагрузок из одного облака в другое должно быть преднамеренным – важное слово для гибридных облачных и пограничных архитектур, говорит технический евангелист Red Hat Гордон Хафф.

4 подхода к перемещению облачных рабочих нагрузок

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

1. Разработайте критерии для принятия решения о том, что куда идет

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

«Есть много причин, по которым нужно решить, где разместить рабочую нагрузку», - говорит Мэтт Уоллес, технический директор Faction. «Самое сложное возникает, когда нет правильного ответа, потому что у вас есть команды или партнеры в разных облаках или вам нужен доступ к разным сервисам».
Поэтому сосредоточьтесь на реальных причинах, которые важны для вас, и позвольте им направлять ваш выбор. Уоллес приводит несколько примеров:
* близость к другим приложениям и данным, также известная как «гравитация данных» и часто являющаяся движущим фактором, когда производительность/задержка являются серьезной проблемой;
* сотрудничество с другими командами и партнерами (если они используют определенное облако), возможно, также имеет смысл;
* набор инструментов, доступных в конкретном облаке – не все они одинаковы;
* географические/локальные проблемы;
* стоимость (подробнее об этом ниже);
* масштаб – например, разница между предсказуемой, стабильной рабочей нагрузкой и нагрузкой, которая, вероятно, будет расти или будет иметь много скачков потребности в ресурсах.

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

Выбор облака также не является универсальным для всех, особенно когда вы выходите за рамки базовой инфраструктуры.

«Инфраструктурные услуги – это ставка в любой облачной среде», - говорит Эрик Дробишевски, старший архитектор Liberty Mutual Insurance. «Помимо этих основных услуг, определите ключевые элементы поставщиков общедоступных облачных сервисов, которые повышают ценность вашего бизнеса, и постарайтесь использовать их для более быстрого повышения ценности».

2. Убедитесь, что все и все хорошо сочетаются друг с другом

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

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

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

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

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

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

3. Управляйте и оптимизируйте затраты

Затраты на облачные вычисления часто упрощаются до абсолютов и крайностей, таких как «Облако дешевле!» (что не всегда верно) или «Боже, почему мой счет за облако такой большой?» (причин может быть много).

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

«Если вы настроите трехуровневую архитектуру автоматического масштабирования в облаке, чтобы справляться с тем, что можно было бы сделать за ничтожную долю затрат, используя шлюз API и бессерверную функцию, вы сильно переплатите за облако», - говорит Уоллес.

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

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

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

С точки зрения переносимости рабочей нагрузки (и затрат на облачные вычисления в целом), есть две большие области, на которых следует сосредоточиться.
Наглядность: эффективное управление облачными затратами сводится к вашей способности ответить на вопрос: «Кто что использует?» Уоллес четко формулирует вопрос с финансовой точки зрения: «Кто сколько денег тратит на какие услуги?»
Если это черный ящик, вам будет трудно достичь своих целей по затратам.

Потоки данных: перемещение облачных рабочих нагрузок может привести к дополнительным (а иногда и неожиданным) затратам, связанным с потоком данных в среду и из среды, обычно называемым входом (in) и выходом (out) данных.

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

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

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

«Это никогда не бывает более драматичным, чем с сетевыми потоками, когда в общедоступном облаке можно настроить сетевой шлюз для подключения ваших виртуальных сетей, где вы платите за шлюз 2,40 доллара в день, но можете отдать за передачу данных 10 800 долларов в день», - говорит Уоллес.

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

4. Делайте вещи простыми и быстрыми для разработчиков

Наконец, не забывайте о своих разработчиках. В наши дни опыт разработчиков решает все.

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

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

По словам Уоллеса, идеальным сценарием, сочетающим готовность к работе в нескольких облаках с большим опытом разработчиков, может быть бессерверная модель, которая выглядит примерно так: «Разработчики могут работать локально или в облачных средах разработки, практически не имея инфраструктуры для обслуживания, а такие инструменты, как throttling limits, встраиваются в такие компоненты, как API-шлюзы чтобы избежать создания неконтролируемого кода в процессе разработки из-за безудержных затрат».
Отличные инструменты, которые сводят к минимуму трения между написанием, тестированием и развертыванием кода, полезны как для бизнеса, так и для разработчиков, а также являются основой для достижения реальной переносимости рабочей нагрузки.

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

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

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

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

Ссылка на источник