Облачные вычисления: Ждите головную боль в случае использования мультиоблачных приложений

Данная заметка Дика Вейсингера (Dick Weisinger – на фото) была опубликована 14 августа 2020 года на блоге компании Formtek.

Под «облачной задержкой» (cloud latency) понимают замедление, имеющее место при отправке и получении данных через облако. Приложения, работающие в рамках одного и того же сервиса (например, AWS или Azure), обычно не нуждаются в использовании внешних сетей за пределами своих сервисов и могут легко работать с небольшой задержкой или практически без неё.

Ряд параметров может повлиять облачную задержку. К ним относятся (см. https://diginomica.com/why-enterprises-need-distinction-between-multiple-clouds-and-multi-cloud-latter-requires-careful ):

• Архитектура и топология, используемые поставщиком облачных услуг,


• Пары регионов во внутриоблачных ссылках,


• Расстояние между клиентом и облачным регионом,


• Интернет-провайдер, чьи услуги используются для доступа к облаку

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

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

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

Так что имеется веская причина для того, чтобы не создавать мультиоблачные приложения, - но всегда есть исключения. Помня о возможных проблемах, подумайте о словах, сказанных директором по производственным вопросам (Chief Operating Officer) компании MESTEC Марком Карлтоном (Mark Carleton, https://www.linkedin.com/in/mcarleton/?originalSubdomain=uk ) о приложении, предназначенном для работы одновременно в облачных центрах Oracle и Microsoft (см. https://diginomica.com/mestec-goes-multi-cloud-oracle-and-msft-become-saas-provider-its-own-right ):

«Мы разработали приложение-демонстратор, имевшее три основных особенности. Мы легко и быстро портировали наше веб-приложение на сервисы веб-приложений MSFT. Мы портировали нашу базу данных на ATP (Oracle). Затем пришлось немного поработать с Microsoft и Oracle, чтобы убедиться, что всё это нормально работает в публичном облаке, и понять, как подобное разделение приложения на части повлияет на задержку и производительность.

К нашему облегчению и удивлению, мы обнаружили, что в общедоступном Интернете приложение работает лучше, чем в условиях нашей унаследованной инфраструктуры в едином центре обработки данных. Преимущества лучших в своём классе платформ как услуги (PaaS) в этих двух средах намного перевешивают недостатки, связанные с размещением компонентов приложения в разных облаках».

Дик Вейсингер (Dick Weisinger)

Источник: блог компании Formtek
http://formtek.com/blog/cloud-computing-expect-headaches-with-multi-cloud-applications/