Бизнес должен быть подвижным. Чтобы оставаться на плаву, та или иная компания должен периодически менять бизнес-практики, экспериментировать. Вся эта деятельность фиксируется в виде изменений в приложениях, базах данных, отчетности или инфраструктуре предприятия. А вот она уже, особенно у крупных компаний, не столь подвижна и не всегда поспевает за последними изменениями технологической моды. Во времена активного продвижения облачных технологий некоторые компании даже готовы смириться с риском lock-in (моновендорной привязки), передоверяя свои инфраструктуры отдельным облачным провайдерам, пишет Мэт Эсей на портале ZDNet.

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

Такое количество несовместимого друг с другом архитектурного изобилия определённо доставляет неудобства CIO, поэтому директор по маркетингу Red Hat Тим Итон надеется, что однажды разнородную сетевую инфраструктуру удастся связать в одно целое на уровне приложений.

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

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

Времена, когда облачные вендоры преподносились как нечто, без чего предприятие не может обойтись, прошли. По крайней мере, их активность уже не вызывает такого эффекта, как раньше — предприятия не ведутся на тренды и подходят к выбору поставщиков более хладнокровно. «Вообразить себе, что пользователи будут перемещать контейнеры между облаком AWS и Rackspace с поминутной тарификацией — это утопия», — полагает Денни Бредбери из The Register. Сходной точки зрения придерживается аналитик Redmonk Джеймс Гавернер: «У организаций имеется два варианта обеспечения переносимости приложений в облаке: либо они обращаются к мультиоблачной модели, либо выбирают под требования отдельных приложений и рабочих нагрузок конкретных провайдеров. Если же избран первый вариант, следует иметь в виду, что всё, что лежит вне базовых возможностей IaaS, потребует дополнительных расходов на управление».

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

Вот приблизительная схема. Вначале предприятиям следует определиться с тем, какие облачные провайдеры в чём сильны. К примеру, если требуется решить задачи из области машинного обучения, то чаще всего обращаются к Google. Для запуска программных кодов без выделения серверов и управления ими — AWS Lambda. Ну а если возникла необходимость модернизировать унаследованные приложения, то тогда лучшим выбором будет Microsoft Azure. Учитывая многообразие приложений среднестатистического предприятия и то, что для их развертывания не существует универсального вендора, управление мультиоблаком становится нетривиальной задачей.

Эксперт в области облачных технологий Бернард Голден говорит: «Вы наверняка посчитаете, что использование инструментов управления, связывающих нескольких индивидуальных облачных провайдеров в единую структуру управления, является эффективным средством снижения затрат на подготовку кадров. Впрочем, на практике этот подход означает, что вы лишаете себя части функционала, который предлагается провайдерами IaaS/PaaS». Другими словами, если вы хотите применять всё лучшее, что имеется в арсенале AWS, Microsoft Azure и Google Cloud, кроссплатформенные средства управления вам не помогут. К сожалению, это означает, что пока что предприятия находятся в полуподвешенном состоянии — этап онпремис они переросли, но вот полноценно попасть в облако пока что не могут.

Переход в облако: что для этого нужно? Отвечая на этот вопрос, соучредитель Rishidot Кришнан Субраманиан заявил, что для этого важен правильный подбор слоя платформенной абстракции: «Это тот ключ, который облегчит вашу жизнь в мультиоблаке. Его роль в повышении производительности разработки сложно переоценить, к тому же он помогает снизить затраты». Кто предлагает нужный слой абстракции и как его выбрать? Эсей считает, что выбор на самом деле не сложен: это инструменты PaaS, предлагаемые такими провайдерами, как Red Hat (OpenShift) или Pivotal (CloudFoundry).

По словам Итона, OpenShift является готовой унифицированной платформой для создания приложений с собственным слоем платформенных абстракций. «У вас должны быть средства абстрагирования от тех вещей, которые делают ваш код уникальным. В конце концов, меня не заботит происхождение инфраструктуры», — сказал он. Однако почти каждый крупный вендор, предлагающий услуги подключения к публичному облаку, стремится вывести на рынок свои эксклюзивные сервисы. Например, AWS Lambda, как и другие подобные сервисы, позволяет обходиться без инфраструктуры, но при этом тесно интегрирован с другими сервисами Amazon. «Это большая сила, но вместе с ней приходит большой lock-in», — подмечает Гавернер. По его словам, чем больше разработчики используют уникальные инструменты, тем они сильнее к ним привязываются.

Как следствие, по ходу написания приложений они создают изолированные базы данных или файлы. «Lock-in затрагивает уровень данных. Это не функциональный уровень и не программная прослойка. DynamoDB и др. невозможно перенести», — сказал разработчик Браян Леруа. А ведь слова этого девелопера противоречат самой сущности облачных сервисов, которые и были созданы для того, чтобы вольно оперировать данными. Свободное перемещение данных в среде ИТ-специалистов принято называть «data gravity». Этот термин в 2010 г. ввёл в обиход CIO Basho Technologies Дейв Макрори. В более широком понимании он обозначает рост числа или массы данных, которые генерируются по мере увеличения количества приложений и сервисов.

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

Как выбрать правильного провайдера? Понятно, что этот выбор непрост, считает Эсей. Взять хотя бы обычно предваряющую её логику рассуждений: «Если у меня имеется несколько развернутых в облаке узлов приложений, это значит, что я работаю в нескольких сетях. Как мне от этого избавиться? Где гарантии, что приложение использует для подключения локальных данных ближайшие облачные ресурсы?». По словам Моргана, в роли лучшего советчика по этим вопросам будет выступать сообщество. Но первым делом вам следует ознакомиться со спецификациями брокера. В декабре прошлого года Cloud Foundry запустила проект Open Service Broker API. Цель проекта — создание промышленных стандартов, которые позволят разработчикам запускать безконтейнерные сервисы вне кластера и использовать их как контейнеры. Ключевыми основателями проекта выступили EMC, HP, IBM, Intel, Pivotal, SAP и VMware.

В Google уверены, что «этот проект является тем, чего требуют наши клиенты и станет связующим звеном успешного применения мультиоблаков». К инициативе Open Service Broker API подключилась и Red Hat. При помощи открытого API она надеется расширить охват клиентов для своей платформы OpenShift. Подчёркивая значение последней, компания называет её «новым RHEL». Старший директор Red Hat по проектированию систем и инжинирингу Дэниел Рик утверждает, что постепенное превращение RHEL из традиционной двоичной среды выполнения приложений на одиночных серверах в масштабируемую платформу мультиконтейнерных приложений и архитектуру для микросервисов отвечает потребностям её клиентов.

В итоге OpenShift стала общей средой выполнения как для традиционных, так и облачных контейнеризированных приложений, работающих в любой точке гибридной облачной инфраструктуры. Платформа предоставляет разработчикам возможность запуска приложений, написанных на языках Java, Python, PHP и Ruby, с использованием фреймворков JBoss, Spring, Seam, Weld, CDI, Rails и др. Из баз данных поддерживаются MySQL, EnterpriseDB (PostgreSQL), Couchbase и MongoDB. Внедрение такого обилия инструментов позволяет разработчикам заботиться о качестве софта, а не заниматься переноской кода из одного облака в другое. Ещё это говорит о том, что Red Hat взялась за осуществление желаний сообщества Open Source, которое одним из первых обеспокоилось по поводу проблем мультиоблачности.

Пока Red Hat занимается добавлением инструментов в OpenShift, приближая мечту всех CIO об единой среде разработки, такие платформы, как AWS, Microsoft Azure и Google Cloud фокусируются или на обрезании функционала, или на создании уникальных опций. В долгосрочной перспективе такая стратегия не увенчается успехом, считает Гавернер, и даже более того — вскоре сообщество Open Source начнёт наращивать выпуск собственных API и платформ для облачной гибридной среды, оказывая давление на проприетарных вендоров. «Удобство — вот самое главное приложение», — сказал он. Сегодня девелоперы получают его из подмножества разрозненных облаков, но недалёк тот день, когда мир Open Source попытается свести онпремис и частные облачные ресурсы вместе, делая удобное ещё более удобным.